面经策

Agent 智能体的工作过程是怎样的？ ​

  • 标签：大模型、AI、Agent

🏛 业务架构师 ​

Agent 的工作过程本质是"感知—规划—行动—观察"的循环（ReAct 范式的工程化）：

1. 感知输入：接收用户任务（"帮我把这批线索按意向分级并发送跟进邮件"），连同上下文（对话历史、用户身份、可用工具清单）装配进模型。

2. 规划：模型分析任务，拆解步骤（先查线索数据→定义分级标准→逐条评估→草拟邮件），决定第一步调用什么工具。复杂 Agent 会显式产出计划（Plan）并支持人工确认。

3. 行动：调用工具——执行查询、检索、代码运行，每个动作带着参数真实执行。

4. 观察：工具返回结果进入上下文，模型核对是否符合预期——数据够不够、结果对不对。

5. 迭代或终止：不满意就修正再来（换查询条件、改分步策略）；满足条件则汇总产出最终结果。整个循环由框架（AgentExecutor/LangGraph）驱动，每步留痕。

业务视角看两个关键设计：一是终止条件——最多循环 N 次、预算上限、重复检测，防止死循环烧钱；二是人在回路——高风险动作（发邮件、改数据）前插入人工确认节点。Agent 循环每转一圈都是真金白银的 token，把"循环次数×单圈成本"作为业务指标监控，是 Agent 运营的基本功。

🏗 系统架构师 ​

Agent 的工作过程本质是一个**"感知-决策-行动-观察"的状态机循环**，我按一次任务的生命周期讲：

  • 接收任务：用户输入（或上游 Agent 委托）进入，加载会话上下文 + 长期记忆 + System Prompt，组装首版上下文；
  • 规划：模型分析任务，分解子目标（显式 Planner 或 ReAct 隐式规划），决定策略（直接回答 / 需要检索 / 需要工具）；
  • 行动执行：输出结构化动作——工具调用（Function Calling/MCP）、检索、代码执行、子 Agent 委派；执行层真实运行（沙箱内），必要时等待人工审批；
  • 观察回填：执行结果（Observation）写回上下文；超大结果先压缩/落盘，只回填摘要 + 引用；
  • 迭代决策：模型基于新状态判断——够了就产出答案，不够继续下一步，走偏了自我修正（Reflexion）；
  • 终止与交付：满足终止条件（任务完成 / 步数上限 / 预算耗尽 / 用户中断），产出结果 + 过程记录（审计轨迹）。

贯穿全程的横切机制：上下文管理（窗口预算分配：System + 记忆 + 历史 + 工具结果）、记忆读写（异步）、护栏校验（每步输入输出）、状态持久化（checkpoint 支持断点恢复）。

架构本质：这就是一个以 LLM 为决策核、以工具为执行器、以上下文为工作内存的分布式任务处理系统——可靠性靠熔断、幂等、可回放三大件兜底。

💻 全栈开发专家 ​

Agent 的工作过程本质是一个「感知-决策-行动-观察」循环：

  1. 感知输入：接收用户消息/事件（定时器、webhook、文件变更），连同上下文一起进入处理；
  2. 上下文组装：System Prompt + 对话历史（裁剪/摘要后）+ 长期记忆检索结果 + 可用工具列表；
  3. 决策（LLM 推理）：模型分析当前状态，输出「思考」和下一步动作——回复用户，或调用某工具（名称+参数）；
  4. 行动执行：运行时执行工具调用（带权限校验、超时、沙箱），拿到结果；
  5. 观察反馈：工具结果（或错误信息）追加进上下文，回到第 3 步；
  6. 循环终止：模型给出最终答案，或触发终止条件（步数/token/时间预算超限、人工中断）；
  7. 后处理：记忆写入、审计日志、计费统计、结果格式化输出。
输入 → 组装上下文 → LLM 决策 ─┬─ 最终回答 → 结束
                ↑             └─ tool_call → 执行 → 观察结果 ─┘

工程关键点：循环必须有硬刹车（max_steps、recursion_limit、token 预算）；工具报错要转成模型可读的信息喂回去，让模型有机会自纠（这比直接抛异常中断体验好得多）；每步打 trace（LangSmith/自研），否则多步循环出问题完全是黑盒。