Agent 基础概念
从最开始的网页版的 ChatGPT 出现，到演进出 Dify 等 Workflow，从 Cursor 的 AI Coding 开始， Agent 产品开始初具雏形，进而开始出现各类 Agent 产品，如 Manus、Openclaw等。Agent 是一个全新的产品形态，不同于以往只能在聊天页面进行对话的 AI，Agent 更像是有了手脚的数字生命，能够与世界进行交互。
1. 常见的 Agent 产品
认识 Agent 最简单的方式就是去了解 Agent产品，同样输入一句自然语言，不同产品能看到的内容和能执行的动作并不相同：
| 产品形态 | 主要环境 | 常见动作 | 典型边界 |
|---|---|---|---|
| ChatGPT 等网页聊天助手 | 当前对话、用户上传的资料 | 生成文本、分析附件、回答问题 | 通常由用户提供资料，网页聊天本身不会持续操作用户的业务环境 |
| Cursor 等 Coding Agent | 本地或远程代码仓库、终端、测试环境 | 搜索、读取、编辑、运行命令和测试 | 能力集中在软件工程环境，修改范围受工作区和权限限制 |
| Manus 等任务型 Agent | 网页、浏览器会话、云端工作区 | 搜索网页、填写表单、整理文件、生成交付物 | 任务执行时间更长，需要处理网页变化、账号授权和失败恢复 |
| OpenClaw 等个人环境 Agent | 本地文件、消息渠道、日历和用户授权服务 | 收发消息、读写文件、调用 API、响应事件 | 贴近个人环境，权限和隐私范围决定可用能力 |
| Workbuddy 等工作协作助手 | 企业知识、任务、文档和协作系统 | 检索资料、创建任务、同步进度、协同产出 | 需要遵守组织权限、数据隔离和审批规则 |
我十分建议你去把市面上的主流 Agent 产品体验一下，时刻关注最新的 Agent 产品进展，时刻知晓在什么场景下，用什么 Agent 产品是最合适的。
2. Agent 与传统 AI 的区别
设想这样的任务：
下周要举办一次产品研讨会。请调研行业趋势和竞品方案，整理参会人关注的问题，写出一版 PRD，邀请研发和设计同事评审，并在会前生成议程和材料清单。
传统网页聊天助手可以根据用户提供的资料生成一份初稿，但搜索最新信息、读取团队知识库、判断日历空档、创建协作任务和跟踪评审意见，仍需要用户在多个页面之间手工搬运信息。
而对于一个具备工具和 Runtime 的 Agent，则会把整个任务拆成一条可执行的工作链：
- 调用搜索工具收集行业趋势、竞品发布信息和公开案例。
- 调用网页读取或文档解析工具，提取来源、日期、结论和引用位置。
- 加载产品调研 Skill，使用团队约定的访谈问题、PRD 模板和评审清单。
- 从知识库检索历史项目，避免重复调研，并标记仍缺少的证据。
- 生成 PRD 初稿，把结论与来源、假设、待验证问题关联起来。
- 查询日历和协作系统，提出评审时间，创建任务并邀请研发、设计等协作者。
- 根据评审意见修改 PRD，运行格式检查和引用检查，生成议程、材料清单与待办。
这条链路中，搜索、网页读取、知识检索、文档写入、日历、任务和消息都是不同工具；产品调研 Skill 提供领域规则和模板；协作者提供新的观察和反馈。Agent 根据每一步的结果选择下一步，Runtime 负责权限、执行和记录。
3. Agent 的定义与核心组成
3.1 Agent 是什么
Agent 是一个围绕目标运行的软件系统。它持续接收观察、选择动作并根据结果推进任务，Runtime 负责把这些决策放入受控的执行流程。
可以用四个问题描述一次 Agent 任务：
| 问题 | 对应概念 | 说明 |
|---|---|---|
| 要达到什么结果？ | 目标（Goal） | 例如“形成可评审的 PRD，并在会前完成材料准备” |
| 现在知道什么？ | 观察（Observation） | 搜索结果、文档内容、日历空档、同事反馈和工具返回值 |
| 可以做什么？ | 动作（Action） | 搜索、读取、生成、编辑、创建任务、发消息或请求确认 |
| 什么时候结束？ | 终止（Termination） | 达到验收标准、等待用户、失败、取消或超过预算 |
Agent 的运行轨迹可以概括为：
目标 → 观察 → 决策 → 动作 → 新观察 → … → 验证与交付动作改变环境，环境产生新观察，新的观察又会影响下一次决策。这个循环是 Agent 和一次性文本生成之间最重要的差别。
3.2 两层系统模型
工程上常用两条公式描述 Agent 系统：
Agent = LLM + Context + Tools
Agent System = Model + Runtime + Environment这两条公式描述两个层次：第一条概括 Agent 的决策组成，第二条描述能够实际运行的系统边界。第一条中的 Tools 由 Runtime 暴露，第二条中的 Runtime 负责把模型提出的候选动作转换为经过授权的执行，并把 Environment 的结果带回任务状态。
3.3 LLM、Context 与 Tools 的分工
上面的第一条公式给出了 Agent 的组成。三部分共同支撑一次任务：
| 部分 | 负责什么 | 研讨会场景中的例子 |
|---|---|---|
| LLM | 理解目标、组织计划、选择动作、综合结论 | 判断先补充竞品资料，还是先询问研发约束 |
| Context | 提供当前目标、状态、证据和规则 | 用户要求、搜索结果、PRD 草稿、评审意见和权限范围 |
| Tools | 获取信息或改变环境 | 搜索、网页读取、知识库、文档、日历、任务和消息 |
三部分需要协同设计：Context 提供判断所需的信息，LLM 选择下一步，Tools 负责获取信息或改变环境。Context 缺少状态摘要时，长任务容易反复处理已经完成的步骤；工具范围不足时，模型只能停留在建议层面。
3.4 观察空间和动作空间
Agent 能力的上限，通常由两个空间共同决定：
- 观察空间：允许进入 Context 的信息范围。没有被读取、检索或暴露给模型的内容，对它来说就是未知。
- 动作空间：Runtime 允许执行的操作集合。模型即使知道解决办法，也只能使用被授权的动作。
| 场景 | 观察空间 | 动作空间 |
|---|---|---|
| 产品研讨会 Agent | 趋势资料、竞品页面、历史 PRD、参会人反馈、日历 | 搜索、读取、生成 PRD、创建任务、邀请评审、发通知 |
| 代码 Agent | 需求、目录、源码、测试输出、Git diff | 搜索、读取、编辑、运行测试 |
| 网页操作 Agent | 截图、DOM、焦点元素、操作反馈 | 点击、输入、滚动、拖拽、提交 |
| 个人助理 | 消息、日历、文件、用户偏好 | 发消息、建日程、读写文件、调用业务接口 |
扩展 Agent 能力，需要同时补充信息入口和可控动作。例如增加“日历读取”后，系统才有机会根据真实空档安排会议；增加“引用检查”后，系统才有机会验证 PRD 的证据覆盖。
3.5 Agent 与相邻形态
除了 Agent，还有一些 RAG、Workflow 等类似的概念，区分这些的关键，在于观察下一步由谁决定：
| 形态 | 下一步由谁决定 | 研讨会场景中的表现 |
|---|---|---|
| LLM 问答 | 模型生成回答后结束 | 根据用户粘贴的材料写一段活动方案 |
| RAG | 程序预设检索流程 | 从指定知识库检索历史 PRD 后回答问题 |
| Workflow | 代码安排固定步骤 | 固定执行“表单→审批→通知→归档” |
| Agent | 模型根据新观察选择动作 | 搜索、调研、写 PRD、协作、复审之间动态切换 |
RAG 可以是 Workflow 中的一步，也可以成为 Agent 的检索工具。
当路径稳定、输入输出清楚时，Workflow 更容易测试，而路径取决于搜索结果、协作者反馈和实时系统状态时，Agent 循环更有价值。
4. LLM：Agent 的大脑
4.1 LLM 的作用
LLM 在 Agent 中承担四类认知工作：
- 从自然语言中提取目标、约束和完成标准。
- 根据当前 Context 形成计划或选择下一步。
- 在工具集合中选择动作并生成参数。
- 综合观察、证据和验证结果，形成结论或调整路径。
模型拥有语言和代码方面的先验知识，但当前项目的事实、日历状态、权限和协作反馈都需要通过 Context 或工具提供。真实副作用由 Runtime 和外部系统完成。
4.2 LLM 请求与响应协议
LLM 协议同时规定请求和响应两端：请求把系统规则、用户目标、历史消息、工具定义和工具结果交给模型；响应返回文本、结构化内容、工具调用、停止原因、用量或错误。OpenAI Chat Completions/Responses 和 Anthropic Messages 属于模型调用协议，本节只用它们说明这组共同语义。
MCP、ACP 等协议位于更外层的连接边界：MCP 主要连接 Agent Host 与工具、资源和提示，ACP/A2A 等协议用于客户端或 Agent 之间的协作。它们会在《常见协议》中单独展开，这里只需要知道它们与 LLM 请求/响应协议处于不同层次。
| 方向 | 典型内容 | 作用 |
|---|---|---|
| 请求（request） | system、messages、tools、tool_choice | 描述模型应遵循的规则、当前上下文和可用动作 |
| 响应（response） | message、content、tool_calls/tool_use、finish_reason/stop_reason、usage | 返回模型输出、候选动作、结束状态和调用统计 |
下面看两种常见模型调用协议，再抽取它们共同表达的语义。
OpenAI Chat Completions
在 Chat Completions 中，系统规则、用户请求、助手历史和工具结果都位于 messages；工具能力通过 tools 描述；tool_choice 控制工具选择策略。
{
"model": "gpt-5",
"messages": [
{"role": "system", "content": "你是产品研讨会助手，所有外部资料都要记录来源。"},
{"role": "user", "content": "调研下周研讨会主题，写出一版带引用的 PRD。"},
{"role": "assistant", "content": "我先收集行业趋势和竞品资料。"}
],
"tools": [
{
"type": "function",
"function": {
"name": "search_web",
"description": "搜索公开网页并返回标题、摘要、日期和链接。",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string"},
"time_range": {"type": "string", "enum": ["week", "month", "year"]},
"max_results": {"type": "integer", "minimum": 1, "maximum": 20}
},
"required": ["query"]
}
}
}
],
"tool_choice": "auto"
}模型返回工具调用时，assistant.tool_calls 包含调用 ID、工具名和参数；Runtime 执行后通过 role: tool 和 tool_call_id 回填结果。Responses API 将输入和输出拆成 message、function_call、function_call_output 等事件，适合更细粒度的流式处理。
Anthropic Messages
Anthropic Messages API 把系统指令放在顶层 system，messages 主要承载用户和助手消息，工具定义使用 input_schema，工具调用和结果使用内容块：
{
"model": "claude-sonnet",
"max_tokens": 2048,
"system": "你是产品研讨会助手，结论必须区分事实、假设和待验证问题。",
"messages": [
{"role": "user", "content": "搜索竞品资料并整理成 PRD 结构。"}
],
"tools": [
{
"name": "search_web",
"description": "搜索公开网页并返回来源信息。",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"max_results": {"type": "integer", "minimum": 1, "maximum": 20}
},
"required": ["query"]
}
}
],
"tool_choice": {"type": "auto"}
}模型会在 content 中返回 tool_use 块：
{
"stop_reason": "tool_use",
"content": [
{
"type": "tool_use",
"id": "toolu_search_01",
"name": "search_web",
"input": {"query": "产品研讨会 竞品趋势", "max_results": 10}
}
]
}Runtime 以 tool_result 内容块回填，并通过 tool_use_id 关联原调用。
两种协议的共同语义
字段名称虽然不同，但每轮调用都在表达以下信息：
| 语义 | OpenAI | Anthropic |
|---|---|---|
| 系统规则 | messages[role=system] | 顶层 system |
| 用户与历史 | messages | messages |
| 工具定义 | tools[].function.parameters | tools[].input_schema |
| 模型动作 | assistant.tool_calls 或 function_call | tool_use 内容块 |
| 工具结果 | role: tool + tool_call_id | tool_result + tool_use_id |
| 停止原因 | finish_reason | stop_reason |
Runtime 内部应保存供应商无关的事件，例如 user_input、assistant_message、tool_call、tool_result、state_update 和 final。适配层再将这些事件转换成具体协议。
5. Context：Agent 逻辑载体
5.1 Context 的准确含义
Context 是某个决策点实际送入模型、并会影响这次输出的信息集合。它来自请求 JSON 的多个部分，不能简单理解为“最近几轮聊天”。以 OpenAI Chat Completions 为例：
| 请求字段 | 是否属于 Context | 进入模型的作用 |
|---|---|---|
messages[].role=system | 是 | 角色、规则、权限和输出要求 |
messages[].role=user | 是 | 当前目标、约束和补充信息 |
messages[].role=assistant | 是 | 之前的计划、回答和已提出动作 |
messages[].role=tool | 是 | 工具观察、证据、错误和状态变化 |
tools[].function.name/description/parameters | 是 | 当前可用动作及参数约束 |
model | 否 | 选择哪个模型服务请求 |
temperature、max_tokens | 否 | 控制采样和输出资源 |
tool_choice | 部分 | Runtime 对工具选择的控制策略 |
对应的 Context 可以抽象成：
{
"context": {
"rules": "messages[role=system]",
"goal": "messages[role=user]",
"history": "messages[role=assistant]",
"observations": "messages[role=tool]",
"available_actions": "tools"
}
}在 Anthropic Messages 中，Context 的对应关系是：顶层 system 提供规则，messages 中的文本和图片承载目标与历史，tool_result 内容块提供观察，tools[].input_schema 描述动作参数。Responses API 则把同样内容拆成 input 项目和输出事件，Runtime 仍然需要把它们组合为当前决策所需的 Context。
5.2 Context 的组织方法
可以把 Context 设计成一张工作台：
- 稳定规则和工具定义放在固定前缀，便于缓存和复用。
- 当前目标、验收标准、状态摘要和待办放在动态区域。
- 搜索结果、文档片段和协作者反馈附带来源、时间和截断标记。
- 结构化记录已完成步骤、证据、假设、资料缺口和预算。
- 对独立调研任务使用独立上下文，主任务只接收结论与证据。
- 将用户指令、系统规则、工具观察和外部网页文本明确分层，外部文本按资料处理。
长任务中，完整历史保留过程，状态摘要负责表达当前进度，知识库保存可复用资料。三者的用途不同，混成一段长文本会降低检索和决策质量。
6. Tools：Agent 的手脚
6.1 为什么需要工具
LLM 只能处理送入 Context 的信息并生成输出。产品研讨会任务中的最新竞品页面、团队 PRD、日历空档和评审意见，通常都不在模型的初始 Context 里；创建任务、写入文档、邀请同事和发送通知也需要真实系统执行。工具把这些能力变成 Runtime 可以调用的接口。
工具把模型无法直接获取的信息和无法直接完成的操作接入 Runtime。模型提出调用请求，程序层负责权限、成本和副作用管理。
6.2 LLM 协议中的工具封装
在 OpenAI 协议中，工具封装在 tools[].function：name 是动作名称，description 帮助模型选择，parameters 使用 JSON Schema 描述参数。在 Anthropic 协议中，对应字段是 name、description 和 input_schema。两者都把“工具说明”作为模型输入的一部分。
协议中的工具结果应带调用 ID，成功时返回结构化数据，失败时返回错误类型、可重试性和用户可读说明。Runtime 据此把结果回填给模型，模型再修正参数、切换工具或结束当前路径。
6.3 工具调用中的角色分工
| 角色 | 职责 |
|---|---|
| LLM | 根据 Context 选择工具并生成参数 |
| Runtime | 校验并调度执行，控制权限、预算、风险、超时和幂等性 |
| Tool Adapter | 将参数转换为 CLI、SDK、SQL、HTTP 或协作平台调用 |
| Environment | 执行动作并返回真实状态 |
将模型输出直接交给 shell 或数据库，会把参数错误放大成真实副作用。Runtime 必须掌握执行权。
6.4 常见工具、Skill 与协作
产品研讨会 Agent 可能使用以下能力：
| 能力 | 工具示例 | 产出 |
|---|---|---|
| 感知 | search_web、read_document、query_knowledge | 来源、摘要、历史结论 |
| 生成与编辑 | write_prd、apply_patch、update_doc | PRD、议程、材料清单 |
| 协作 | find_reviewer、create_task、send_message | 评审任务、邀请和回执 |
| 事件 | calendar_event、Webhook、定时器 | 时间触发和后续提醒 |
| 验证 | check_citations、validate_schema、run_tests | 引用覆盖、格式和质量反馈 |
Skill 通常提供一组任务说明、模板、脚本和领域约束，例如“产品调研 Skill”可以规定竞品字段、PRD 章节和评审清单。协作工具把同事、其他 Agent 或业务系统接入观察和动作空间。Function Calling 负责结构化调用，MCP 负责能力发现与连接，Skill 负责按需加载任务知识，三者可以由同一个 Runtime 组合使用。
6.5 工具设计要点
- 名称表达具体能力，例如
search_web、read_prd、create_review_task。 - schema 写清必填字段、枚举值、路径范围和数量上限。
- 结果包含摘要、数据、来源、耗时和截断标志。
- 错误区分参数错误、权限拒绝、超时、限流和业务失败。
- 写文档、发消息、创建任务和修改数据返回变更摘要，必要时先预览并请求确认。
- 高风险操作使用专用接口和最小权限，保留审计记录与恢复路径。
7. Agent Runtime：让循环可执行、可恢复
7.1 Runtime 的职责
Runtime 是 Agent 的任务控制器，负责：
- 创建任务并保存目标、权限和预算，组装当前 Context 并筛选可用工具。
- 解析模型输出，校验参数、路径、风险和资源消耗，再执行工具并标准化结果。
- 更新状态、轨迹、证据和产物，根据验证结果决定继续、重试、重规划、暂停或交付。
- 记录 trace，支持中断恢复、评估和审计。
前面的架构图中，Runtime 位于模型和真实环境之间：它把用户目标变成受控 Context，把模型动作变成经过授权的调用，再把环境反馈写回任务状态。这样模型可以保持灵活，系统仍然拥有明确的执行边界。
7.2 长任务的状态模型
单轮对话结束后，模型可以直接返回结果；产品研讨会这类任务会跨越多轮模型调用、多个工具和人工评审。Runtime 如果只保留当前对话，就难以判断哪些步骤已经完成、哪些证据支撑了结论、哪些动作仍在等待确认。因此，Runtime 需要维护一份与界面无关的机器可读状态，并在每次工具返回后更新它。
这份状态至少要回答四个问题：任务要达成什么目标、当前处于哪个阶段、已经积累了哪些证据和产物、还剩多少预算与权限。以研讨会任务为例：
{
"goal": "完成产品研讨会调研、PRD 和评审安排",
"status": "reviewing",
"plan": [
{"id": "research", "status": "done"},
{"id": "prd", "status": "done"},
{"id": "review", "status": "in_progress"},
{"id": "agenda", "status": "pending"}
],
"evidence": ["3 个竞品来源", "2 条用户反馈", "研发评审意见"],
"artifacts": ["prd-v1.md"],
"budget": {"turns": 12, "tool_calls": 24, "elapsed_ms": 18000},
"permissions": {"docs": ["product/"], "calendar": "read", "messaging": "draft"}
}这里的 status 描述任务整体阶段，plan[].status 描述子步骤进度；evidence 和 artifacts 记录后续决策可以复用的事实与产物，budget 和 permissions 约束 Runtime 的执行范围。状态需要可序列化并定期保存 checkpoint，网络中断、进程重启或人工接管时，Runtime 就能从最近状态继续，减少重复搜索和重复发送通知。界面上的进度条只是这份运行状态的一种展示方式。
7.3 预算、终止和错误恢复
Runtime 应限制轮次、token、工具次数、时间和成本，并检测重复动作和无进展循环。常见终止条件包括：验收标准已满足且有证据支持、用户要求暂停、缺少必要信息、达到预算、权限不足或出现不可恢复错误。
错误处理先分类再决定策略：临时网络错误和限流可以退避重试；参数错误需要修正输入；权限拒绝需要请求授权或更换方案；路径越界、数据损坏和危险副作用应停止相关动作并保留现场。
8. 三种常见 Agent Runtime 模式
8.1 ReAct：每一步都读取反馈
ReAct 把判断、动作和观察交替放入同一个循环。回到研讨会任务，Agent 可以先搜索行业趋势，再根据结果决定是否深入某个竞品；如果来源不足，就继续搜索；如果已有证据满足要求，就进入 PRD 撰写。
它适合探索、调试和资料收集，路径灵活；需要通过重复动作检测、轮次预算和状态摘要控制无效循环。
8.2 Plan-and-Execute：先规划，再执行
对于“调研—写 PRD—邀请评审—生成议程”这类阶段较多的任务，可以先生成带依赖和完成标准的计划，再由 Executor 执行每一步。搜索结果或协作者反馈改变原有假设时，Runtime 触发重新规划。
这种模式适合长任务、进度展示和多种产物管理。实际实现经常采用“高层计划 + 每一步内部运行短 ReAct”的组合。
8.3 Reflection：让结果接受检查
Reflection 在一个阶段完成后加入评估器，检查结果是否满足事实、格式和业务规则。PRD 可以检查引用覆盖、需求与用户问题的对应关系、字段完整性和评审意见是否已处理；发现问题后，Agent 带着反馈重新生成或继续调用工具。
反馈越接近真实验收，Reflection 越有用：代码使用测试、Lint 和构建；数据处理使用 schema 和统计规则；文档使用引用检查、模板校验和人工评审。模型自评可以提供线索，外部证据仍然是主要依据。
8.4 模式选择
| 模式 | 控制方式 | 适合任务 | 需要防范 |
|---|---|---|---|
| ReAct | 每轮根据观察选择动作 | 搜索、调试、开放探索 | 重复、路径漂移、过早结束 |
| Plan-and-Execute | 步骤、依赖、重规划 | 长任务、研究、报告 | 计划过期、执行僵化 |
| Reflection | 结果评估、反馈、修正 | 代码、文档、结构化产物 | 自评缺少证据、成本增加 |
先采用能覆盖任务的最小模式，再根据失败类型增加规划或检查。模式越多，状态、预算和可观测性要求越高。