上一篇我讲 Agent，不想把它讲成“多个 AI 角色互相聊天”。

因为在真实工程里，Agent 的核心不是角色扮演，而是：

让大模型在工具、状态、反馈和权限边界内完成任务。

但继续往下学 Agent，很快会遇到一堆术语：

ReAct、Tool Calling、Action、Observation、State、Memory、Planning、Workflow、Guardrails、Human-in-the-loop、Tracing、MCP、Multi-Agent……

它们到底在 Agent 系统里解决什么问题？

这一篇只做一件事：

把 Agent 里的核心术语翻译成人话，并说明每个组件在“任务执行循环”里负责什么。

一、先看 Agent 的执行循环

一个 Agent 系统最核心的循环可以这样理解：

Goal → State → Reasoning / Planning → Action / Tool Call → Observation → State Update → Continue / Stop / Human Review

翻译成人话就是：

• 用户给一个目标。
• 系统读取当前任务状态。
• 模型判断下一步要做什么。
• 如果需要外部能力，就请求调用工具。
• 工具返回结果。
• 系统把结果写回状态。
• 模型基于新的状态继续判断。
• 直到任务完成、失败、超过步数限制，或者进入人工确认。

OpenAI Agents SDK 官方文档里的 agent loop 也是类似语义：Runner 调用 LLM；如果模型返回 final output，循环结束；如果模型产生 tool calls，就执行工具、追加结果，然后重新运行循环；如果 handoff，则更新当前 agent 和输入后继续运行。

所以，理解 Agent 术语，先记住这条线：

目标 → 状态 → 决策 → 行动 → 观察 → 更新状态 → 继续或停止

这条线就是本文的主线。后面所有术语，都不是孤立概念，而是在这条任务执行循环里承担不同职责。

二、ReAct：让模型一边判断，一边行动

论文ReAct: Synergizing Reasoning and Acting in Language Models。这篇论文的核心思想是：让语言模型在任务过程中交替生成 reasoning traces 和 task-specific actions。简单说，就是模型不是一次性把答案说完，而是一边判断下一步，一边执行动作，通过外部环境或知识源拿到反馈，再继续处理任务。论文中也明确提到，reasoning traces 帮助模型跟踪和更新行动计划，actions 让模型可以连接外部知识库或环境获取信息。

可以把 ReAct 简化成这个结构：

Reasoning：我现在需要知道订单状态 Action：调用 get_order Observation：订单已签收 3 天 Reasoning：还需要知道售后政策 Action：调用 get_refund_policy Observation：破损商品需要上传图片凭证 Final：生成客服回复

注意，这里说的 Reasoning 不等于把模型完整思维链展示给用户。在工程里，更应该理解成“模型对下一步动作的决策依据”。

一句话：

ReAct 解决的是：模型如何在“判断—行动—观察—再判断”的循环中推进任务。

三、Tool Calling：模型请求工具，应用执行工具

Tool Calling 是 Agent 的入口。

没有 Tool Calling，模型只能生成文本。
有了 Tool Calling，模型才能请求外部能力，比如查询订单、检索政策、调用搜索、生成草稿、提交工单。

但这里有一个关键边界：

模型不是直接操作系统，模型只是请求调用工具。

Spring AI 官方文档对此说得很清楚：虽然通常把 tool calling 称为模型能力，但工具调用逻辑由客户端应用提供；模型只能请求工具调用并提供输入参数，应用负责执行工具调用并返回结果，模型不会直接访问工具背后的 API。

所以 Tool Calling 的真实流程是：

模型：我要调用 get_order，参数是 orderId=A1001 应用：检查这个工具是否存在 应用：检查当前用户是否有权限 应用：执行 get_order 应用：把工具结果返回给模型 模型：基于工具结果继续回答或继续调用工具

这也是为什么 Agent 安全不能只写在 prompt 里。

不能只告诉模型：

不要越权。 不要乱查数据。 不要直接退款。

真正可靠的方式是：

工具注册时限制功能 调用前做权限检查 参数进入工具前做校验 高风险动作进入人工确认 所有工具调用写入审计日志

一句话：

Tool Calling 不是把权限交给模型，而是让模型提出动作请求，由应用程序执行和约束。

四、Action：Agent 准备执行的下一步

Action 是模型选择的下一步动作。

它不一定都是“调用 API”。在 Agent 系统里，Action 可以有很多种：

调用工具 检索文档 查询数据库 询问用户 生成草稿 请求人工确认 结束任务

比如用户问：

我的订单签收三天了，商品破损，可以退吗？

模型的第一个 Action 可能不是回答，而是：

{"type":"CALL_TOOL","toolName":"get_order","arguments":{"orderId":"A1001"}}

但要注意：

Action 是模型提出的下一步，不代表模型真的拥有执行权限。

真正执行 Action 的，应该是后端应用里的 Tool Executor、Policy Gate 或 Workflow Engine。

这里要注意，Action 更像“动作意图”，不是已经执行过的真实动作。

五、Observation：外部世界给 Agent 的反馈

Observation 是工具或环境返回给 Agent 的结果。

比如查询订单后，系统返回：

{"orderId":"A1001","status":"SIGNED","signedDaysAgo":3,"productCategory":"electronics"}

这不是最终答案，而是 Agent 下一步决策的依据。

有了 Observation，模型才能继续判断：

订单已签收 3 天 → 还需要查售后政策 → 调用 get_refund_policy

• 如果没有 Observation，Agent 就只是凭模型常识继续猜。
• 如果 Observation 不可信，Agent 后续判断也会被带偏。

所以 Observation 的质量很重要：

• 工具返回结构是否稳定；
• 字段是否清晰；
• 错误是否明确；
• 数据是否属于当前用户；
• 是否需要脱敏；
• 是否能被记录和复盘。

所以Observation 不是最终答案，而是 Agent 下一轮判断的依据。

六、State：当前任务进行到哪一步

State 是 Agent 的当前任务状态。

比如一个客服 Agent 的 State 可以长这样：

{"goal":"判断订单是否可以退货","step":2,"knownFacts":{"orderStatus":"SIGNED","signedDaysAgo":3,"productCategory":"electronics"},"toolCalls":["get_order"],"missingInfo":["refund_policy","damage_photo"],"needHumanApproval":false}

State 解决的是这些问题：

任务目标是什么？ 现在进行到第几步？ 已经调用过哪些工具？ 已经知道哪些事实？ 还缺哪些信息？ 是否需要人工确认？ 是否已经结束？

没有 State，Agent 就没有连续任务能力，只是一次问答。

LangGraph 官方文档把 persistence 分成 checkpointers 和 stores：checkpointers 用于保存线程级 graph state，支持对话连续性、人类介入、time travel 和故障恢复；stores 用于长期、跨线程记忆，比如用户偏好、事实和共享知识。

这说明 State 不是装饰，而是 Agent 能持续执行任务、暂停、恢复和复盘的基础。

一句话：

State 负责当前任务的短期进展。

七、Memory：跨任务保留下来的长期信息

Memory 很容易被讲得很玄。

工程上可以直接区分：

State：当前任务内的短期状态。 Memory：跨任务、跨会话保留下来的长期信息。

State 例子：

这个退款任务已经查过订单，但还没查售后政策。

Memory 例子：

这个用户偏好中文回复。 这个商家退款通常需要人工确认。 这个项目的技术栈是 Spring Boot + Spring AI。

Memory 的难点不是“存起来”，而是：

• 什么信息值得存；
• 存多久；
• 什么时候检索；
• 什么时候更新；
• 什么时候删除；
• 如何避免把错误信息长期保存；
• 如何避免隐私信息被过度记忆。

所以 Memory 不是让 AI “像人一样记住你”，而是一个存储、检索、更新、过期和权限控制问题。

一句话：

State 负责当前任务，Memory 负责长期上下文。

八、Planning：下一步怎么走

Planning 是 Agent 对任务步骤的规划。

但这里有一个容易误解的点：

不是所有 Agent 都需要复杂 Planning。

如果路径很固定，比如：

解析 JD → 解析简历 → 匹配岗位要求 → 找缺口 → 生成建议 → 证据检查

这更适合 Workflow。

如果路径不确定，比如用户一句话里同时问退款、物流、发票、投诉，系统需要根据中间结果不断调整下一步，这时 Planning 的价值才更明显。

Anthropic 在《Building effective agents》里明确区分 workflow 和 agent：workflow 是 LLM 和工具按照预设代码路径被编排；agent 则是 LLM 动态决定自己的流程和工具使用方式。Anthropic 还建议开发者先从简单方案开始，只有复杂度确实能改善结果时再增加 agentic system。

所以Planning 的价值不是“让 Agent 看起来更聪明”，而是让它在路径不确定时能选择下一步。

九、Workflow：开发者提前设计好的任务路线

Workflow 是固定流程。

比如简历场景：

解析 JD → 解析简历 → 匹配岗位要求 → 找出缺口 → 生成改写建议 → 做证据检查 → 输出风险提示

Workflow 不是低级方案。

很多真实业务里，Workflow 反而比 Agent 更可靠。因为路径清晰、结果可测、失败点可定位、成本更可控。

你可以这样区分：

路径固定：优先 Workflow 路径不确定：再考虑 Agent

也可以换成代码理解：

// Workflow：下一步主要由开发者写死parseJd();parseResume();match();rewrite();checkEvidence();returnresult;

而 Agent 是：

// Agent：下一步由模型根据状态和工具结果决定while(!state.isFinished()){AgentDecisiondecision=llm.decideNextStep(state,tools);executeOrStop(decision);}

一句话：

Workflow 是人设计路线，Agent 是模型在边界内动态选择路线。

十、Agent Loop：把决策、工具、反馈串成循环

Agent Loop 是 Agent 的运行循环。

OpenAI Agents SDK 文档明确把 agent loop 列为核心能力：它处理工具调用，把结果发送回 LLM，并持续运行直到任务完成。

代码上可以这样理解：

while(!state.isFinished()){AgentDecisiondecision=llm.decideNextStep(state,tools);if(decision.isToolCall()){ToolResultresult=toolExecutor.execute(decision.toolName(),decision.arguments());state.observe(result);}if(decision.isFinalAnswer()){returndecision.answer();}if(decision.needHumanApproval()){returnpauseForHumanReview(state);}}

Agent Loop 至少要处理四类情况：

继续调用工具 生成最终答案 请求用户补充信息 暂停等待人工确认

同时还要有停止条件：

最大步数 最大成本 最大工具调用次数 超时 无法获得必要信息 风险过高

一句话：

Agent Loop 把模型决策、工具执行、结果反馈和状态更新串成一个闭环。

十一、Guardrails：不是提示词，而是系统边界

Guardrails 是 Agent 的安全和质量边界。

它不只是 prompt，而应该包括：

输入检查 输出检查 工具权限检查 参数校验 敏感信息过滤 高风险动作拦截 人工确认 审计日志

OpenAI Agents SDK 文档里，guardrails 被用于对用户输入和 agent 输出做检查与验证；OpenAI 的 guardrails/human review 文档也把 guardrails 与 human review 放在一起：guardrails 自动验证输入、输出或工具行为，human review 则让运行暂停，等待人或策略审批敏感动作。

OWASP LLM06:2025 Excessive Agency 也直接指出，LLM-based system 常被赋予调用函数、连接其他系统或通过工具执行动作的能力；Agent 系统通常会使用前一次 LLM 输出继续指导后续调用。其风险根源通常是 excessive functionality、excessive permissions、excessive autonomy。

所以 Guardrails 的重点不是让模型“自觉别乱来”。

而是：

模型看不到不该看的工具 工具本身只暴露必要功能 工具调用前必须校验权限 写操作必须人工确认 敏感结果必须脱敏 所有高风险动作必须可追踪

一句话：

Guardrails 是系统层边界，不是模型自律。

十二、Human-in-the-loop：高风险动作交给人

Human-in-the-loop 是人工介入。

它解决的是：

当 Agent 准备执行高风险动作时，谁来拍板。

比如：

查询订单：自动执行 生成退款说明：自动执行 提交退款申请：人工确认 删除用户数据：默认禁止

LangChain 的 Human-in-the-Loop 文档描述了一个典型模式：当模型提出可能需要审查的动作，比如写文件或执行 SQL，middleware 可以暂停执行并等待决策；LangGraph 的 interrupt 机制也支持在指定点暂停 graph execution，等待外部输入后再继续，并通过 persistence 保存状态。

这对 Agent 很关键。

因为 Agent 最大的变化是：它不只是回答，它会行动。只要会行动，就必须区分哪些动作能自动执行，哪些动作必须确认，哪些动作默认禁止。

一句话：

Human-in-the-loop 解决的是高风险动作的最终控制权。

十三、Tracing / Observability：为什么 Agent 必须能复盘

Tracing 是记录 Agent 运行过程。

你需要知道：

模型为什么调用这个工具？ 调用了哪个工具？ 工具参数是什么？ 工具返回了什么？ 是否失败？ 失败在哪一步？ 是否触发人工确认？ 最终回答用了哪些证据？ 这次任务花了多少 token 和成本？

OpenAI Agents SDK 把 tracing 列为核心能力，用于可视化、调试和监控 agentic workflows；GitHub 上的 OpenAI Agents SDK 仓库也把 Agents、Tools、Handoffs、Tracing 等列为核心概念。

没有 Tracing，Agent 一出错，你只能看到最终答案。

有了 Tracing，你才能知道：

错在意图识别？ 错在工具选择？ 错在工具参数？ 错在权限判断？ 错在证据不足？ 错在模型最终生成？

一句话：

没有 Tracing，就没有可复盘的 Agent。

十四、MCP：工具和上下文接入协议，不是 Agent 本体

MCP 是 Model Context Protocol。

它不是 Agent 本身，而是让 LLM 应用连接外部数据源和工具的一种开放协议。MCP 官方规范写得很清楚：MCP enables seamless integration between LLM applications and external data sources and tools，并为 LLM 应用提供标准化方式来共享上下文、暴露工具和能力、构建可组合集成与工作流。

所以 MCP 解决的是：

工具怎么注册？ 资源怎么暴露？ 上下文怎么提供？ Agent 怎么发现外部能力？ 不同系统怎么用统一协议连接？

但 MCP 不是装上就安全。

MCP 官方安全最佳实践文档专门列出 confused deputy、session hijack、local MCP server compromise、OAuth authorization URL validation、scope minimization 等安全问题；MCP reference servers 仓库也提醒，参考服务器主要用于演示 MCP 特性和 SDK 用法，不是生产就绪方案，开发者需要根据自己的威胁模型实现安全措施。

一句话：

MCP 是 Agent 接外部能力的一种协议，主角仍然是任务执行和权限治理。

十五、Multi-Agent：责任拆分，不是角色扮演

Multi-Agent 是多个 Agent 协作。

但它不应该是 Agent 入门起点。

很多教程喜欢写：

产品经理 Agent 架构师 Agent 开发者 Agent 测试 Agent

然后让它们互相聊天。

这种演示看起来很有意思，但工程价值不一定高。

真正需要 Multi-Agent 的场景通常是：

不同 Agent 负责不同专业任务 不同 Agent 拥有不同工具权限 需要一个 Agent 审查另一个 Agent 的输出 任务路径复杂到单个 workflow 难以维护 需要长期异步协作

OpenAI Agents SDK 把 “Agents as tools / Handoffs” 作为协调和委派多 Agent 工作的机制；GitHub 上 OpenAI Agents SDK 仓库也把 handoffs 描述为把任务委派给其他 agent 的核心概念之一。

一句话：

Multi-Agent 是责任拆分，不是让几个角色聊天凑热闹。

十六、AgentBench：为什么 Agent 不能只看单次回答

AgentBench 是一个用于评估 LLM-as-Agent 的 benchmark。它关注的是多轮、开放式、交互环境里的推理和决策能力，而不是只看一次问答表现。论文指出，可用 Agent 的关键障碍包括 poor long-term reasoning、decision-making 和 instruction following。

这对开发者很重要。

因为 Agent 不是回答一次就结束，它会经历：

多轮决策 工具调用 环境反馈 状态更新 错误恢复 停止判断

一个模型单次回答很强，不代表它作为 Agent 就稳定。

真正要看的是：

它能不能长期保持目标？ 它会不会重复调用无用工具？ 它会不会忘记前面查到的信息？ 它会不会在证据不足时乱答？ 它会不会在高风险动作前停下来？

一句话：

Agent 的能力不能只靠单轮问答评估，而要放进交互式任务里评估。

十七、把所有术语串起来

现在把这些词放回同一个客服 Agent 场景里。

用户问：

我的订单签收三天了，商品破损，可以退吗？

Agent 的执行过程可以这样理解：

Goal： 判断这个订单是否可以退货。 State： 当前只知道用户提出了退款问题，还不知道订单状态、商品类目和售后政策。 Planning / Reasoning： 需要先查订单，再查售后政策。 Action / Tool Call： 调用 get_order。 Observation： 订单已签收 3 天，商品类目是 electronics。 State Update： 写入订单状态和商品类目。 Action / Tool Call： 调用 get_refund_policy。 Observation： 售后窗口 7 天内，但破损需要图片凭证，且不能自动退款。 Guardrails： 退款提交属于 WRITE_REVIEW，不能自动执行。 Human-in-the-loop： 如果用户要提交退款申请，需要用户确认或客服审核。 Final Answer： 说明当前可能符合售后时间窗口，但需要上传破损图片；可以生成申请草稿，但不能直接提交退款。 Tracing： 记录本次 Agent Run 的工具调用、参数、结果、证据和风险标记。

这就是 Agent 术语之间的关系。

不是每个术语都孤立存在，而是共同服务于一件事：

让大模型在边界内完成一个多步骤任务。

十八、最后用一张表收束

如果只记一句话：

Agent 不是一个单独技术点，而是一套任务执行结构。

• ReAct 解释它怎么“判断—行动—观察”。
• Tool Calling 让它能请求外部工具。
• State 让它知道任务进行到哪一步。
• Memory 让它保留长期上下文。
• Workflow 让固定路径更可控。
• Guardrails 限制它不能乱行动。
• Human-in-the-loop 让人类接管高风险动作。
• Tracing 让整次执行可以复盘。
• MCP 让外部工具和上下文更标准化地接入。
• Multi-Agent 只在职责和权限确实需要拆分时才上。

参考资料

• ReAct: Synergizing Reasoning and Acting in Language Models

• Anthropic: Building effective agents

• OpenAI Agents SDK

• Spring AI Reference: Tool Calling

• LangGraph Persistence / Human-in-the-loop

• Model Context Protocol Specification / Security Best Practices

• OWASP LLM06:2025 Excessive Agency

• AgentBench: Evaluating LLMs as Agents

本篇部分内容含AI辅助生成请注意辨别。我是 Ryan，一个专注于可信 AI 应用工程的开发者，我的技术博客。相比让 AI 生成更多内容，我更关心它的回答是否有证据，过程是否可追溯，结果是否经得起验证。