当前位置：首页 > news >正文

Agent 基础

news 2026/6/5 8:57:39

Agent 基础：从 LLM 到真正能完成任务的智能体

如果说大模型是“会思考和表达的大脑”，Agent 就是把大脑放进一个可执行系统里：它有目标、有上下文、有工具、有反馈回路，也有必要的安全边界。

这篇文章适合产品经理、AI 应用设计者和刚开始接触 Agent 的同学。它不追求把所有 SDK API 讲完，而是先把 Agent 的底层概念讲清楚：Agent 和 LLM 到底差在哪，Function Calling、Handoff、Guardrails、Memory、MCP、A2A 分别解决什么问题，以及产品经理在设计 Agent 系统时应该关注哪些判断点。

一句话先讲清楚 Agent

在今天的语境里，一个真正可用的 Agent 通常不是“一个更聪明的聊天机器人”，而是一个围绕目标持续行动的系统。

可以用一个简化公式理解：

Agent = LLM + Memory + Planning + Tools + Action

换成产品语言就是：

Agent = 大脑 + 记忆 + 计划 + 工具 + 执行能力

LLM 负责理解、推理、生成和判断；Memory 负责保存和调用历史信息；Planning 负责把目标拆成步骤；Tools 让 Agent 能访问外部世界；Action 则代表它真的可以做事，而不仅是给建议。

所以，更准确的定义是：

Agent 是一个能够围绕目标感知上下文、制定计划、调用工具、观察结果、调整策略，并持续推进任务完成的 AI 系统。

这个定义里最关键的词不是“AI”，而是“持续推进任务”。

LLM 和 Agent 的本质区别

LLM 的典型工作方式是一次性生成：

输入 -> 推理 -> 输出

用户问一个问题，模型给一个答案，任务就结束了。

Agent 的工作方式更像循环执行：

目标 -> 思考 -> 调用工具 -> 获得结果 -> 继续思考 -> 继续行动 -> 完成目标

也可以写成经典的 ReAct 循环：

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 不应该直接编一段答案，而应该先拆解：

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 框架。

一个完整工具调用闭环通常是：

用户请求 -> 模型判断是否需要工具 -> 模型生成工具名和参数 -> 系统执行工具 -> 工具返回结果 -> 模型基于结果组织最终回答 -> 用户收到答案或任务结果

可以把两者粗略区分为：

Function Calling = 模型决定调用什么、传什么参数 Tool Calling = 系统真正执行工具，并把结果交回模型

不过在 OpenAI 官方文档里，Function Calling 也常被归入 Tool Calling 的大范畴：工具是提供给模型的功能，工具调用是模型请求使用工具，工具输出则是系统返回给模型的结果。

Structured Outputs 为什么重要

当 Agent 要和业务系统交互时，“差不多像 JSON”是不够的。字段丢失、枚举值乱写、类型不一致，都会让后端执行失败。

Structured Outputs 的价值在于让模型输出遵守你定义的 JSON Schema。用于函数参数时，可以显著降低工具调用失败率；用于最终回答时，可以让前端或下游系统稳定消费结构化结果。

例如一个情绪识别字段，不应该只靠提示词说“请输出 happy、sad、angry 之一”，而应该通过 Schema 限制：

{"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 之间如何通信、协作和交接任务。

可以这样区分：

MCP = Agent 连接工具 A2A = Agent 连接 Agent

例如：

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 产品，不是让模型“自由发挥”，而是在清晰目标、可靠工具、可控边界和持续评估之间取得平衡。