AI Agent

复核范围（2026-10-03）

本页采用 LLM Agent 的工程语境，不试图覆盖全部经典智能体定义。工作流区分与常用模式回查 Anthropic 官方方法文，ReAct 回查原论文；七部分拆解、失败清单与建设顺序是本页综合建议，不是统一行业标准或性能保证。未复现实验，也不提供最新产品能力排名。

当前结论

AI Agent 是能够根据环境反馈反复选择动作、调用工具并维护任务状态的 LLM 系统。它与普通问答的差别不在“会不会思考”，而在于是否拥有一个可持续的观察—决策—行动—验证闭环。

工程上可先评估更简单的调用或工作流，再在步骤无法预先固定、工具需要动态选择时增加自主性。Anthropic 将预定义流程与模型动态控制的 Agent 区分开来；这是一套有用的设计口径，不是所有社区共用的唯一分类。官方方法文

模型只是系统的一部分；可靠性不能只靠模型，还需要检查上下文、工具契约、状态、权限、评测和恢复机制。

范围与边界

单轮生成
  → 固定工作流
  → 带路由或评审的动态工作流
  → 单 Agent 开放循环
  → 多 Agent 协作

向右移动可能增加适应性，也会引入更多状态和失败方式；成本、延迟是否增加应实测，不能把这张图理解为严格的单调性能排序。Agent 不是“所有自动化”的新名字：如果任务可以稳定写成固定步骤，可先用工作流建立可预测、可测试的基线。

系统组成

本页用七个工程关注点拆解 Agent；它们不一定对应七个独立组件，也不是所有原型必须具备的最小定义：

组成	回答的问题
模型	如何解释目标、生成候选决策？
上下文	当前应该看见哪些指令、事实和约束？
工具	可以对外部世界执行哪些类型化动作？
状态与记忆	任务进度、证据和跨会话经验存在哪里？
策略与权限	哪些动作允许、拒绝或必须审批？
Harness	如何调度、重试、压缩、记录和恢复？
Eval	如何判断结果、轨迹、副作用与成本？

常见的“增强型 LLM”可概括为：

LLM + Retrieval + Tool Use + State/Memory + Guardrails + Evaluation

常用控制模式

表中的链式、路由、并行、评审优化和编排分工参照 Anthropic 的模式说明；ReAct 指交替生成推理与动作、利用环境反馈更新后续行为。其余名称用于描述常见控制结构，不暗示它们属于同一标准。ReAct 原论文

模式	控制方式	适用场景
Prompt Chaining	固定顺序串联	步骤明确、每步可单独验证
Routing	根据输入分流	不同任务需要专门处理器
Parallelization	并行生成或校验	可独立拆分、需要投票或聚合
ReAct	观察后选择下一工具	通用动态工具调用
Plan-and-Execute	先计划、再逐步执行	依赖较强的多步任务
Evaluator-Optimizer	生成与独立评审循环	有清晰 Rubric 的迭代产出
Orchestrator-Workers	中心动态分派子任务	子任务数量和类型事先未知
Multi-Agent	多角色、上下文或权限隔离	并行收益大于协调成本

这些模式在不同框架中名称和 API 不同，但控制结构相近。先明确任务状态机、工具边界和验证方式，再选择框架，比从框架反推架构更稳妥。

是否需要 Agent

同时满足越多条件，Agent 越有价值：

• 需要多轮读取环境并据此改变计划。
• 无法预先确定下一步工具或子任务。
• 中间产物可以被机器检查，失败可以恢复。
• 任务价值足以覆盖额外推理、观测和治理成本。
• 权限和最大副作用可以被清晰限制。

下列情况更适合普通程序或工作流：

• 规则稳定、输入输出结构明确。
• 一次错误代价高，但无法建立可靠验证器。
• 任务很短，工具选择没有不确定性。
• Agent 需要过宽权限才能获得少量便利。

多 Agent 还需要额外证明：上下文隔离或并行处理带来的收益，确实大于通信、重复推理和冲突消解成本。详见多智能体系统。

运行闭环

目标与完成标准
  → 获取最小必要上下文
  → 规划或选择一个可逆动作
  → 策略检查与工具执行
  → 观察结构化结果和环境状态
  → 验证：继续 / 修复 / 升级审批 / 停止
  → 记录轨迹并输出可审计结果

长任务应显式设置预算、最大步数、重试上限、检查点和终止条件。错误恢复不是“再问模型一次”，而是保存状态、分类失败、改变策略并防止重复副作用。

系统级评测

Agent 的评测对象是模型、提示、工具、检索、记忆、权限、环境和版本共同组成的系统。至少分开测量：

• 结果质量：任务是否完成，引用和事实是否正确。
• 轨迹质量：是否选择了必要且合理的步骤。
• 可靠性：多次运行、长任务和异常环境下是否稳定。
• 安全性：是否越权、泄密或产生未批准副作用。
• 效率：延迟、Token、工具调用和人工介入成本。

一次成功不能证明可靠；只看最终答案也会遗漏危险轨迹。评测与可观测性应在设计工具和状态协议时同时建立，而不是上线前补装。

主要争议

“单 Agent 优先”和“多 Agent 能显著增益”并不直接矛盾：前者是默认工程策略，后者通常成立于任务可并行、上下文需要隔离且有协调机制的特定条件。真正需要比较的是同一任务、同一预算和同一完成标准下的系统收益，而不是 Agent 数量。

模型能力提升也不会自动消除 Harness。模型越能承担开放任务，权限、状态、验证和审计的重要性反而越高。

常见失败模式

• 把一个 Prompt 包在循环里就称为 Agent，没有状态和停止条件。
• 工具描述含糊，参数和错误返回不可机器处理。
• 上下文无限增长，把日志和数据库都塞进窗口。
• 生成者同时充当唯一评审者，出现同源盲点。
• 重试没有幂等设计，重复写入或重复付款。
• 只评最终答案，不检查权限、副作用和成本。
• 为追求自主性取消本应保留的审批和回滚点。

实践顺序

1. 写清目标、完成标准和不可接受的副作用。
2. 先实现最小确定性工作流，建立基线。
3. 把工具做成窄接口，返回结构化结果与明确错误。
4. 只在不确定节点引入 Agent 决策。
5. 增加检查点、预算、审批、审计和失败恢复。
6. 用真实任务集持续比较成功率、成本和人工介入率。
7. 只有在单 Agent 的上下文或并行性成为瓶颈时再拆多 Agent。

进入专题

• 构建方法：AI Agent 开发
• 上下文：Context Engineering
• 运行治理：Harness Engineering
• 持续验证：AI Agent 评测
• 权限与隔离：AI Agent 安全
• 外部知识：RAG