AI Agent 全景

学习导航

完成本文后，你将能够

1. 能够区分工作流、工具调用型应用和真正需要循环决策的 Agent，避免为简单任务引入不必要自治性。
2. 能够设计一个带工具 schema、状态、预算、异常恢复、人机审批与日志追踪的 Agent 主循环。
3. 能够为 Agent 建立覆盖任务成功率、工具调用正确性、安全边界、成本延迟和人工接管质量的评估方案。

这个模块解决什么问题

Agent 的核心不是“让模型自己想办法”，而是让模型在受控环境中选择行动、调用工具、观察结果，并在必要时继续规划或交给人。ReAct 论文把 reasoning 与 acting 放在同一循环里：模型不只输出最终答案，还可以把中间推理转化成搜索、查表、执行代码等动作；Toolformer 则说明模型可以学习何时使用外部工具。今天的生产 Agent 通常把这些思想落到结构化工具调用、状态机、审批流、监控和评估上。

一个清醒的判断是：多数业务场景先需要可靠工作流，再需要 Agent。固定步骤、稳定输入输出、错误成本高的任务，往往适合确定性编排加少量模型节点；只有当任务需要动态选择工具、处理不完整信息、跨多步观察环境、或者在失败后尝试替代路径时，Agent 才真正有价值。Agent 不是魔法自动化，而是一种把“不确定决策”显式封装、可追踪、可限制的系统设计。

本模块把 Agent 看成一个“受控行动循环”。它由任务意图、上下文状态、计划器、工具集合、观察结果、记忆、护栏、评估与人类协作组成。你会看到很多模式：提示链、路由、并行化、反思、工具调用、规划、多智能体、记忆、人机协同、异常处理和资源优化。它们不是越多越好，而是用来回答同一个问题：怎样让模型的每一步行动都可解释、可回放、可停止、可改进？

旧稿里的核心公式仍然值得保留，但现在要给它加上工程边界：Agent = LLM + Planning + Memory + Tools。LLM 是认知控制器，负责理解目标、生成候选计划和解释观察；Planning 负责拆解任务、选择下一步或判断是否停止；Memory 负责保留短期状态、长期偏好和历史教训；Tools 负责连接外部世界。真正的生产系统还要在这个公式外面包一层 runtime：权限、预算、日志、审批、评估和回滚。没有 runtime 的 Agent 只是一个会调用工具的 prompt，有了 runtime 才能成为可运营的软件。

核心工作流

这条循环里最重要的是边界。模型可以选择工具，但工具 schema 要明确；模型可以规划，但最大步数、预算和超时要明确；模型可以写入外部系统，但高风险动作要有人审或沙箱执行；模型可以记忆，但记忆要有来源、过期策略和删除机制；模型可以反思，但反思不能替代可量化评估。

生产 Agent 的工程质量常常取决于“失败路径”而不是成功 demo。工具报错怎么办？搜索没有结果怎么办？模型多次调用同一工具怎么办？两个工具返回冲突信息怎么办？用户要求越权操作怎么办？成本超过预算怎么办？如果这些路径没有明确设计，Agent 很快会变成一个昂贵、不可复现、偶尔惊艳但难以信任的黑箱。

旧稿里用 ReAct 解释“边想边做”，这个例子可以保留成 trace 视角。现在不建议把中间推理原样暴露给终端用户，但系统内部仍应记录足够的行动轨迹，方便调试和评估：

用户问题：亚里士多德的老师是谁的老师？
plan: 需要先查亚里士多德的老师，再查这个人的老师。
tool_call_1: search("亚里士多德 老师")
observation_1: 柏拉图
tool_call_2: search("柏拉图 老师")
observation_2: 苏格拉底
final: 苏格拉底

这个 trace 的重点不是让模型“自言自语”，而是让每个外部行动都能被审计：为什么调用这个工具，参数是什么，观察结果是什么，最终答案是否真的依赖这些观察。后续做反思、自检或多智能体互审时，也应该围绕这条轨迹增量增强，而不是让多个 Agent 在没有共享状态和停止条件的情况下互相聊天。

关键概念

概念	它解决什么	使用时要警惕
工作流 vs Agent	工作流适合稳定步骤；Agent 适合动态决策、观察环境和多轮行动。	不要把可确定编排的问题伪装成自治系统。
工具调用	用 schema 把模型输出约束为可执行动作，并让系统层负责执行与校验。	schema 过宽会放大风险；工具结果必须进入 trace，不能只拼回 prompt。
规划与路由	把复杂任务拆成子任务，或选择最合适的模型、工具和路径。	计划并不天然正确，需要预算、停止条件和失败恢复。
记忆	保存用户偏好、任务状态、历史决策或长期知识。	记忆要可解释、可删除、可过期；不要把隐私数据随意注入上下文。
反思与自检	让模型在输出前检查遗漏、冲突和工具结果一致性。	自评容易同源偏差，应配合独立 grader、规则校验或人工抽检。
多智能体	用角色分工、并行探索或互审处理复杂任务。	协调成本、上下文膨胀和责任边界可能抵消收益。
人机协同	在高风险、低置信度或不可逆动作前引入人工审批。	审批点太多会拖慢系统，太少会把风险外包给模型。
评估与监控	用数据集、轨迹、grader 和线上指标持续发现退化。	只看最终成功率不够；还要看工具选择、步骤数、成本、延迟和安全事件。

推荐学习顺序

1. 先读 提示链、路由、并行化 与 反思，建立比单次 prompt 更可靠的工作流基础。
2. 再读 工具调用 与 规划，理解 Agent 循环如何从“生成文本”升级成“选择行动”。
3. 接着读 多智能体协作、记忆管理 与 推理技术，学习在复杂任务里拆角色、保状态和控制上下文。
4. 然后读 异常处理与恢复、人机协同 与 智能体间通信，把系统从 demo 推向可运营。
5. 最后读 资源感知优化、护栏与安全、评估与监控、优先级排序、探索与发现 和 评估方法，补齐生产环境中的成本、风险和持续改进闭环。

如果你刚开始做 Agent，推荐先实现一个窄任务：例如“读取一个工单、检索相关知识、生成处理建议、必要时请求人工确认”。先把工具 schema、trace、异常恢复和评估集做好，再决定是否加入长期记忆、多智能体或复杂规划。

旧稿提到的 21 个智能体设计模式，可以理解为从这个窄任务逐步加能力的菜单，而不是一次性全上。提示链、路由和并行化通常属于“工作流强化”；工具调用、规划和记忆才开始接近 Agent；异常恢复、人机协同、护栏和监控则决定系统能否上线。一个常见的演进顺序是：先把单 Agent 的工具调用做稳定，再加入任务路由；当单任务耗时过长时再做并行化；当失败样本显示需要历史经验时再加记忆；当风险动作出现时再加审批。这样每一项能力都有对应失败样本，不会为了架构好看而膨胀。

实践检查点

• 是否能用一句话说明：这个任务为什么不能用确定性工作流解决，而需要 Agent 循环？
• 每个工具是否都有最小权限、输入 schema、输出 schema、超时、重试和错误分类？
• 是否保存了完整轨迹：用户目标、计划、每次工具调用、观察结果、模型中间决策、最终输出和人工干预？
• 是否设置了最大步数、最大成本、最大执行时间，以及低置信度或高风险动作的审批规则？
• 是否有失败样本集，覆盖工具返回空结果、权限不足、外部系统异常、用户意图冲突和提示注入？
• 是否把评估拆成任务成功率、工具选择准确率、参数正确率、答案忠实度、安全事件率、人工接管率和单位成本？

如果要把练习落成代码，先写一个最小工具 schema，而不是直接接真实生产 API。比如 search_docs(query, top_k)、create_ticket(summary, priority) 和 request_approval(action, reason) 三个假工具已经足够覆盖“检索、写入、审批”三类动作。评估时故意让 search_docs 返回空结果、让 create_ticket 抛出权限错误、让 request_approval 返回拒绝，观察 Agent 是否停止、重试、改写问题或转人工。能处理这些朴素失败路径，再考虑接入真实数据库、浏览器、代码执行器或多 Agent 协作。

版本与边界

截至 2026-08，Agent 工程的稳定核心是结构化工具调用、可回放轨迹、明确护栏和持续评估；具体平台、SDK 与评估产品仍在快速变化。OpenAI 的函数调用、Structured Outputs、Agents SDK 和 agent evals 文档可以作为当前接口参考，但系统设计最好保持厂商中立：把工具 schema、任务状态、评估数据集和审批规则沉淀在自己的应用层，而不是绑死在某个临时 API 形态上。

Agent 的边界同样重要。它不应该默认拥有写权限，不应该在没有证据时伪造观察结果，不应该把长期记忆当成事实数据库，也不应该把“模型反思了一遍”当成安全证明。越靠近金融、医疗、法律、招聘、权限管理和生产运维，越需要最小权限、人类确认、审计日志和可回滚设计。一个好 Agent 的目标不是显得自主，而是在不确定环境里尽可能可靠地完成任务，并在不能可靠完成时及时停下来。

延伸阅读

参考资料

• ReAct: Synergizing Reasoning and Acting in Language Models — Agent 推理-行动循环的经典论文。
• ReAct project page — 论文作者维护的项目页，包含方法说明与示例。
• Toolformer: Language Models Can Teach Themselves to Use Tools — 理解模型学习工具使用的代表论文。
• OpenAI Function calling — 当前工具调用接口与 schema 约束参考。
• OpenAI Structured Outputs — 结构化输出约束，对可靠工具参数和任务状态很重要。
• A practical guide to building agents — OpenAI 面向业务 Agent 设计的实践指南。
• OpenAI Agents SDK — 官方 SDK 文档，适合参考 Agent、工具、handoff 与 tracing 抽象。
• OpenAI Agent evals — Agent 评估指南，强调轨迹、工具调用和任务级指标。
• OpenAI evaluation best practices — 评估数据、grader 与回归检查的通用实践。
• LangSmith evaluation — LangChain 官方评估文档，可参考 trace 与 dataset 工作流。