Agent 基础：从 LLM 到真正能完成任务的智能体
如果说大模型是"会思考和表达的大脑"，Agent 就是把大脑放进一个可执行系统里：它有目标、有上下文、有工具、有反馈回路，也有必要的安全边界。
这篇文章适合产品经理、AI 应用设计者和刚开始接触 Agent 的同学。它不追求把所有 SDK API 讲完，而是先把 Agent 的底层概念讲清楚：Agent 和 LLM 到底差在哪，Function Calling、Handoff、Guardrails、Memory、MCP、A2A 分别解决什么问题，以及产品经理在设计 Agent 系统时应该关注哪些判断点。
一句话先讲清楚 Agent
在今天的语境里，一个真正可用的 Agent 通常不是"一个更聪明的聊天机器人"，而是一个围绕目标持续行动的系统。
可以用一个简化公式理解：
text
Agent = LLM + Memory + Planning + Tools + Action换成产品语言就是：
text
Agent = 大脑 + 记忆 + 计划 + 工具 + 执行能力LLM 负责理解、推理、生成和判断；Memory 负责保存和调用历史信息；Planning 负责把目标拆成步骤；Tools 让 Agent 能访问外部世界；Action 则代表它真的可以做事，而不仅是给建议。
所以，更准确的定义是：
Agent 是一个能够围绕目标感知上下文、制定计划、调用工具、观察结果、调整策略，并持续推进任务完成的 AI 系统。
这个定义里最关键的词不是"AI"，而是"持续推进任务"。
LLM 和 Agent 的本质区别
LLM 的典型工作方式是一次性生成：
text
输入 -> 推理 -> 输出用户问一个问题，模型给一个答案，任务就结束了。
Agent 的工作方式更像循环执行：
text
目标 -> 思考 -> 调用工具 -> 获得结果 -> 继续思考 -> 继续行动 -> 完成目标也可以写成经典的 ReAct 循环：
text
Think -> Act -> Observe -> Think -> Act -> Observe
这也是为什么"会调用工具的大模型"还不一定是 Agent。工具调用只是能力之一，Agent 还需要知道何时调用、如何拆解目标、如何处理失败、什么时候停止、什么时候把任务交给别人。
对产品经理来说，可以用一个很实用的判断标准：
| 类型 | 核心能力 | 典型场景 |
|---|---|---|
| LLM | 生成答案 | 写文案、总结、问答、改写 |
| Workflow | 按预设步骤执行 | 固定审批流、固定数据清洗流程 |
| Agent | 根据目标动态决策 | 调研、排障、销售跟进、复杂客服、自动化运营 |
如果路径稳定、分支有限，Workflow 往往更简单、更可靠；如果任务开放、上下文多变、需要动态选择工具，Agent 才真正有价值。
Agent 系统的五个基础模块
1. Instructions：Agent 的角色和边界
Instructions 不只是"提示词"，它定义的是 Agent 的工作合同：它是谁、要完成什么、不能做什么、优先级是什么、遇到冲突如何处理。
好的 Instructions 通常要回答四个问题：
- 这个 Agent 的职责是什么？
- 它可以使用哪些工具？
- 什么情况必须拒绝、澄清或升级？
- 输出应该符合什么格式和质量标准？
越是企业级场景，Instructions 越不能只写人格设定，而要写清楚业务边界和决策准则。
2. Planning：把目标拆成可执行步骤
Planning 是 Agent 区别于普通问答的重要能力。它需要把"帮我完成某件事"拆成可观察、可执行、可验证的步骤。
例如用户说："帮我分析最近流失用户的原因，并给出召回方案。"
一个 Agent 不应该直接编一段答案，而应该先拆解：
text
1. 查询最近流失用户数据
2. 按用户画像、行为路径、付费状态分组
3. 找到主要流失节点
4. 对比历史留存和触达数据
5. 生成召回策略和实验方案Planning 的难点不是列步骤，而是根据中间结果调整步骤。真正的 Agent 要能在发现数据缺失、工具失败、结论不确定时改变路线。
3. Tools：让模型连接真实系统
Tools 是 Agent 的"手"。没有工具，Agent 只能基于已有上下文给建议；有了工具，它才能查询订单、搜索文档、写数据库、发消息、创建任务、提交代码。
工具设计有三个关键点：
| 设计点 | 说明 |
|---|---|
| 工具粒度 | 太粗会难以控制，太细会增加选择成本 |
| 参数 Schema | 参数越明确，模型越不容易传错 |
| 权限边界 | 高风险工具必须有确认、审计或回滚机制 |
产品经理不一定要写工具代码，但必须能定义"这个 Agent 需要哪些能力，以及哪些能力不能直接放开"。
4. Memory：让 Agent 不只活在当前对话里
Memory 是 Agent 存储、检索和利用历史信息的能力。它可以支持个性化、长期任务和跨会话协作。
常见 Memory 可以分成几类：
| 类型 | 说明 | 例子 |
|---|---|---|
| 短期记忆 | 当前任务中的上下文 | 本轮对话、当前表单、临时计划 |
| 长期记忆 | 跨会话保留的信息 | 用户偏好、历史决策、项目背景 |
| 情景记忆 | 过去发生过的任务经历 | 上次排障过程、上次调研结论 |
| 语义记忆 | 稳定事实和知识 | 产品规则、术语定义、组织结构 |
Memory 和 RAG 容易混淆。简单说，RAG 更像"查外部资料"，Memory 更像"记住用户和任务历史"。在实际系统里，两者常常一起使用：RAG 负责知识库，Memory 负责连续性。
5. State Management：知道任务推进到哪里
State 是对任务进展的结构化记录。它回答的问题是：任务现在处于哪一步？哪些工具已经调用过？哪些结果可信？哪些动作还没做？
没有 State，Agent 很容易重复调用工具、忘记已完成步骤，或者在长任务中丢失目标。对复杂 Agent 来说，State Management 往往比单次模型能力更重要。
Function Calling 与 Tool Calling：模型如何"做事"
Function Calling 本质上是让模型学会输出结构化的工具调用请求：它根据用户意图判断要调用哪个函数，并生成符合 Schema 的参数。真正执行函数的仍然是外部程序或 Agent 框架。
一个完整工具调用闭环通常是：
text
用户请求
-> 模型判断是否需要工具
-> 模型生成工具名和参数
-> 系统执行工具
-> 工具返回结果
-> 模型基于结果组织最终回答
-> 用户收到答案或任务结果可以把两者粗略区分为：
text
Function Calling = 模型决定调用什么、传什么参数
Tool Calling = 系统真正执行工具，并把结果交回模型不过在 OpenAI 官方文档里，Function Calling 也常被归入 Tool Calling 的大范畴：工具是提供给模型的功能，工具调用是模型请求使用工具，工具输出则是系统返回给模型的结果。
Structured Outputs 为什么重要
当 Agent 要和业务系统交互时，"差不多像 JSON"是不够的。字段丢失、枚举值乱写、类型不一致，都会让后端执行失败。
Structured Outputs 的价值在于让模型输出遵守你定义的 JSON Schema。用于函数参数时，可以显著降低工具调用失败率；用于最终回答时，可以让前端或下游系统稳定消费结构化结果。
例如一个情绪识别字段，不应该只靠提示词说"请输出 happy、sad、angry 之一"，而应该通过 Schema 限制：
json
{
"user_sentiment": {
"type": "string",
"enum": ["happy", "sad", "angry"],
"description": "分析用户情绪，只能从 happy、sad、angry 中选择"
}
}需要注意的是，strict: true 通常要求 Schema 满足更严格的约束，例如对象字段需要明确 required，并限制额外属性。它不是"随便写个 JSON Schema 就一定能跑"，而是要按支持的 Schema 子集设计。
Handoffs：让多个 Agent 分工协作
Handoff 是 Agent 之间的任务移交机制。当一个 Agent 判断当前任务更适合由其他专业 Agent 处理时，它会把必要上下文和控制权交给目标 Agent。
它和 Tool Calling 的区别在于：
| 机制 | 发生了什么 | 适合场景 |
|---|---|---|
| Tool Calling | 当前 Agent 调用一个外部能力 | 查订单、搜文档、发消息 |
| Handoff | 当前负责执行的 Agent 发生切换 | 客服转财务、产品转研发、路由到专家 |
常见 Handoff 模式有四种：
| 模式 | 说明 |
|---|---|
| Router 路由模式 | 先由路由 Agent 判断任务类型，再交给专家 Agent |
| Sequential 流水线模式 | 一个 Agent 完成后交给下一个 Agent，例如调研 -> 写作 -> 审校 |
| Manager-Worker 管理模式 | 管理 Agent 拆任务，多个 Worker Agent 并行执行 |
| Dynamic Handoff 动态移交 | 根据中间结果临时决定是否转交 |
在 OpenAI Agents SDK 里，Handoff 可以声明式配置，也可以手动定义触发条件。产品设计时最容易忽略的是：必须写清楚"什么时候不能转交"。否则多 Agent 系统会变成互相甩锅。
Guardrails：Agent 的安全护栏
Guardrails 是用于约束、检查和保护 Agent 行为的一组机制。它的目标不是让 Agent "更聪明"，而是让 Agent 在可控范围内工作。
常见 Guardrails 包括：
| 类型 | 作用 |
|---|---|
| 输入校验 | 判断用户请求是否越界、违规或需要澄清 |
| 输出审核 | 检查回答是否包含敏感信息、幻觉或不合规内容 |
| 工具权限 | 限制 Agent 能调用哪些工具、在什么条件下调用 |
| Tripwire | 高风险动作触发中断，请求人工确认 |
| Handoff 限制 | 限制 Agent 之间随意转交 |
| Context Filtering | 只把必要上下文传给下一个 Agent |
企业级 Agent 里，Context Filtering 特别重要。不是所有历史消息都应该传给下一个 Agent。删除闲聊、无关日志、失败的中间草稿，只保留核心诉求和必要证据，既能降低成本，也能减少模型被噪声带偏。
MCP：Agent 连接外部工具的标准接口
MCP，全称 Model Context Protocol，可以理解为 AI 应用连接外部工具和数据源的标准协议。
它的价值在于：过去每接一个系统都要写一套集成逻辑；有了 MCP，Agent 应用可以用更统一的方式发现工具、读取资源、调用能力。
MCP 的核心角色有三个：
| 角色 | 说明 | 例子 |
|---|---|---|
| MCP Host | 运行 Agent 的应用 | Claude Desktop、Cursor、各类 Agent 产品 |
| MCP Client | Host 内部负责和 Server 通信的组件 | 像一个协议适配器 |
| MCP Server | 真正暴露能力的服务 | GitHub、Notion、Slack、数据库、文件系统 |
MCP Server 通常可以暴露三类能力：
| 原语 | 作用 | 例子 |
|---|---|---|
| Resources | 给模型读取的上下文或数据 | 文档、文件、数据库 Schema、日志 |
| Tools | 可以被调用的行动能力 | 发消息、查订单、创建 Issue、执行查询 |
| Prompts | 可复用的提示词模板 | 代码审查模板、客服处理流程、调研模板 |
对产品经理来说，MCP 的核心意义是"降低集成债"。当企业内部系统越来越多时，Agent 不可能为每个系统单独做一套接入方式。标准化协议会让工具生态更容易复用。
A2A：Agent 连接 Agent
MCP 解决的是 Agent 和工具之间的连接，而 A2A 关注的是 Agent 和 Agent 之间如何通信、协作和交接任务。
可以这样区分：
text
MCP = Agent 连接工具
A2A = Agent 连接 Agent例如：
text
MCP：Agent -> GitHub / Notion / MySQL / Slack
A2A：产品 Agent -> 开发 Agent -> 测试 Agent -> 发布 Agent
如果说 MCP 更像"工具接口标准"，A2A 更像"协作网络标准"。前者让 Agent 能访问外部能力，后者让多个 Agent 能在复杂任务里互相发现、通信和分工。
产品经理设计 Agent 时要问的 10 个问题
做 Agent 产品，不要一上来就问"用哪个模型"。更好的起点是下面这些问题：
- 这个任务是否真的需要动态决策？还是普通 Workflow 就够了？
- Agent 的目标是什么？成功完成的标准是什么？
- 哪些步骤必须由模型判断，哪些步骤应该由确定性代码完成？
- Agent 需要哪些工具？每个工具的输入、输出和权限是什么？
- 哪些动作有风险，必须加人工确认或回滚机制？
- 需要记住什么？哪些信息不应该进入长期记忆？
- 任务状态如何记录？失败后能否恢复？
- 多 Agent 是否真的必要？如果必要，谁负责路由和收敛？
- 如何评估 Agent 的好坏？看准确率、完成率、成本、时延，还是人工接管率？
- 如何观测每次执行过程？能否追踪模型决策、工具调用和失败原因？
最后两个问题尤其重要。Agent 不是一次 prompt 调优就能上线的功能，它更像一个持续迭代的系统。没有评估和观测，就很难知道它到底是在变好，还是只是"看起来更会说"。
小结
Agent 的核心不是"更像人"，而是"更能完成任务"。
它相比 LLM 多了目标循环、工具调用、状态管理、记忆能力、安全护栏和多 Agent 协作机制。Function Calling 解决模型如何结构化地请求工具，Structured Outputs 解决输出契约，Handoff 解决专业分工，Guardrails 解决边界控制，MCP 解决工具生态接入，A2A 则进一步解决 Agent 之间的协作。
对产品经理来说，理解 Agent 的关键不是背概念，而是建立一套设计判断：什么时候该用 Agent，什么时候不该用；哪些能力交给模型，哪些能力交给代码；哪些动作可以自动执行，哪些动作必须有人类确认。
真正好的 Agent 产品，不是让模型"自由发挥"，而是在清晰目标、可靠工具、可控边界和持续评估之间取得平衡。