代码 Agent 的基本执行流程是什么？任务分析、文件检索、编辑和验证如何串起来？
这道题考的是你对代码 Agent 核心执行机制的理解。表面问"流程是什么"，实际上在考察你能不能说清楚：Agent 怎么思考、怎么行动、怎么验证自己的结果。换个问法：代码 Agent 是怎么像一个程序员一样完成任务的？
板块1：Agent 的核心公式和三层架构
先记住一个公式：Agent = LLM + Planning + Tools。
LLM 是大脑，负责理解和决策；Planning 是项目经理，负责把大任务拆成小步骤；Tools 是开发团队，负责具体执行。这三者缺一不可。
代码 Agent 的三层架构就是这个公式的具体落地：
第一层是模型调用层。这是 LLM 的接口，负责和语言模型交互。你给它一个指令，它返回一个响应。
第二层是工具能力层。这里放着代码 Agent 的"手"——能读写文件、执行命令、搜索代码的工具。底层靠 Function Calling 或 MCP 协议把这些工具暴露给模型。
第三层是上下文管理层。模型每次"思考"都要基于上下文，这个模块负责管理历史对话、项目文件结构、当前任务进度，让模型不会"失忆"。
你可以把它想象成一个软件工程团队：LLM 是架构师做决策，Planning 是项目经理拆任务，Tools 是开发团队写代码。三层各司其职，Agent 才能运转起来。
板块2：Agent Loop 的循环执行机制
Agent 怎么工作的？靠的是 Agent Loop——一个"感知→规划→执行→反馈→循环"的闭环。
模型不是一次性把任务做完，而是一轮一轮地迭代。每轮迭代都基于上轮的结果，动态调整下一步该做什么。这就是著名的 ReAct 范式：Reasoning + Acting，一边想一边做。
具体流程是这样的：
模型先思考（Thought）："我要完成这个任务，下一步该做什么？"
然后行动（Action）：调用某个工具
接着观察（Observation）：看工具返回了什么结果
最后基于观察结果进入下一轮思考
类比一下，就像老司机开车。不是先想好全程怎么开再出发，而是看路况（感知）→决定怎么开（规划）→踩油门（执行）→看结果（反馈）→继续调整方向。一边开一边调整，遇到障碍就绕路。
代码 Agent 也是这样，每一轮都在"思考+行动+观察"的循环里，直到任务完成或者判断无法完成。
板块3：代码 Agent 执行流程的四步串连
现在说重点：代码 Agent 具体是怎么串起来完成一个编程任务的？
第一步：任务分析
模型拿到需求后，不会直接动手。它先用思维链（CoT）或者 Plan-and-Execute 模式理解任务：用户要干什么？需要改哪些地方？有没有依赖关系？
类比一下，就像新员工接手项目，第一件事是读需求文档，搞清楚要做什么、做到什么程度。
第二步：文件检索
明确了任务后，Agent 需要找到要改的代码文件。它会用通配符、正则表达式、或者语义搜索来定位目标文件。这就像在项目目录里找相关的代码文件。
第三步：编辑执行
找到了文件，Agent 开始用 Tool Calling 执行编辑操作。读文件、分析代码、修改内容、写回文件。这一步是真正"干活"的部分。
第四步：验证反馈
改完了不能直接交差，需要验证。Agent 会运行测试、执行命令、或者重新读取文件检查结果。然后把验证结果注入上下文（Observation），作为下一轮思考的依据。
这四步不是线性走一遍就完了，而是会循环迭代。如果验证失败，Agent 会分析原因，调整策略，重新执行。这就是为什么代码 Agent 能处理复杂任务——它不是一次性的管道，而是一个能自我纠错的闭环。
板块4：工具定义与调用机制
代码 Agent 能执行操作，靠的是工具系统。这里以 Function Calling 为例说清楚原理。
工具定义用 JSON Schema 描述，核心字段有三个：
- name：工具叫什么
- description：工具是干什么的，让模型能理解什么时候该用它
- parameters：工具需要什么参数
就像餐厅的菜单，清楚写着每道菜叫什么、是什么、怎么点。
调用过程是这样的：
- 模型分析上下文，判断需要调用工具
- 模型生成 tool_call，包含要调用的工具名和参数
- 系统执行工具，把结果返回
- 结果以 role=tool 的消息形式返回，用 tool_call_id 关联调用和结果
关键点在这里：工具结果不是直接"告诉用户"，而是注入到模型上下文里，让模型基于结果继续思考。这就是 Agent Loop 能循环起来的机制——每轮的工具调用结果都会影响下一轮的决策。
MCP 协议也是类似的思路，但它更进一步，把工具、资源、提示词都标准化了，适合构建复杂的 Agent 系统。
板块5：Workflow vs Agent 的选择策略
实际开发中，什么时候用 Workflow？什么时候用 Agent？
记住一个原则：固定流程选 Workflow，探索性任务选 Agent。
Workflow 是预定义的管道，适合步骤清晰、逻辑确定的场景。比如"代码审查 → 风格检查 → 单元测试"这个固定流程，用 Workflow 更高效、更可控、Token 消耗更低。
Agent 适合步骤不固定、需要动态决策的场景。比如"根据 bug 描述找到并修复问题"，Agent 可以自己探索、自己验证。
类比一下：盖简单平房用固定图纸（Workflow），盖摩天大楼需要边设计边施工（Agent）。
对于复杂任务，可以用 Multi-Agent 协作：一个编排 Agent 负责整体调度，多个子 Agent 负责具体执行，它们之间可以互相审查、互相验证。这种架构适合评审、测试、重构这类需要多角色协作的场景。
面试怎么答
基础版（能过的回答）：
代码 Agent 的核心是 Agent Loop 循环执行机制，典型实现是 ReAct 范式：Thought → Action → Observation → Thought 的闭环。具体到编程任务，它通过四步串连完成工作：任务分析（用 CoT 理解需求）→ 文件检索（用通配符/正则定位代码）→ 编辑执行（用 Tool Calling 操作文件）→ 验证反馈（把结果注入上下文驱动下一轮决策）。
Agent 的架构可以理解为三层：模型调用层负责 LLM 交互，工具能力层提供文件读写、命令执行等能力，上下文管理层管理记忆和会话状态，让模型不会在循环中"失忆"。
加分版（让面试官眼前一亮）：
除了基础的 ReAct 范式，你还可以提到 Plan-and-Execute 模式——先规划再执行，适合长任务但动态调整能力弱。Reflection 机制可以叠加使用，让 Agent 自我审查结果，提升输出质量。
实际选型时要区分 Toolkits 和 Skills：Toolkits 是固定逻辑的工具集，Token 消耗低，适合高频操作；Skills 是延迟加载的灵活工具，适合低频但复杂的场景。
MCP 协议值得关注，它把 Tools、Resources、Prompts 标准化了，是构建复杂 Agent 系统的基础。
一句话总结
代码 Agent 通过"任务分析→文件检索→编辑执行→验证反馈"的四步循环，在三层架构支撑下实现自我纠错式的编程任务执行。