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，邀请研发和设计同事评审，并在会前生成议程和材料清单。

传统网页聊天助手可以根据用户提供的资料生成一份初稿，但搜索最新信息、读取团队知识库、判断日历空档、创建协作任务和跟踪评审意见，仍需要用户在多个页面之间手工搬运信息。

即：传统的 AI 对话只能完成一次行的任务，而无法循环多次，自主规划执行。

而对于一个具备工具和 Runtime 的 Agent，则会把整个任务拆成一条可执行的工作链：

1. 调用搜索工具：收集行业趋势、竞品发布信息和公开案例。
2. 调用网页读取或文档解析工具：，提取来源、日期、结论和引用位置。
3. 加载 Skill：使用团队的内部 Skill，规范约定的访谈问题、PRD 模板和评审清单。
4. 知识库检索：检索历史文档，避免重复调研，并标记仍缺少的证据。
5. 首次执行：生成 PRD 初稿，把结论与来源、假设、待验证问题关联起来。
6. 审查阶段：查询日历和协作系统，提出评审时间，创建任务并邀请研发、设计等协作者。
7. 交付阶段：根据评审意见修改 PRD，运行格式检查和引用检查，生成议程、材料清单与待办。

这条链路中，搜索、网页读取、知识检索、文档写入、日历、任务和消息都是不同工具；产品调研 Skill 提供领域规则和模板；协作者提供新的观察和反馈。Agent 根据每一步的结果选择下一步，Runtime 负责权限、执行和记录。

3. Agent 的定义与核心组成

3.1 Agent 是什么

Agent 是一个围绕目标运行的软件系统。它持续接收观察、选择动作并根据结果推进任务，Runtime 负责把这些决策推进到具体的执行流程。

可以用四个问题描述一次 Agent 任务：

问题	对应概念	说明
要达到什么结果？	目标（Goal）	例如“形成可评审的 PRD，并在会前完成材料准备”
现在知道什么？	观察（Observation）	搜索结果、文档内容、日历空档、同事反馈和工具返回值
可以做什么？	动作（Action）	搜索、读取、生成、编辑、创建任务、发消息或请求确认
什么时候结束？	终止（Termination）	达到验收标准、等待用户、失败、取消或超过预算

Agent 的运行轨迹可以概括为：

目标 → 观察 → 决策 → 动作 → 新观察 → … → 验证与交付

动作改变环境，环境产生新观察，新的观察又会影响下一次决策。这个循环是 Agent 和一次性文本生成之间最重要的差别。

3.2 Agent 的组成公式

工程上常用下列公式概括 Agent 的决策组成：

Agent = LLM + Context + Tools

这条公式描述 Agent 最基本的构成：LLM 负责决策，Context 提供判断所需的信息，Tools 负责获取信息或改变环境。三者的具体分工见下一节。

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 中承担四类认知工作：

1. 从自然语言中提取目标、约束和完成标准。
2. 根据当前 Context 形成计划或选择下一步。
3. 在工具集合中选择动作并生成参数。
4. 综合观察、证据和验证结果，形成结论或调整路径。

模型拥有语言和代码方面的先验知识，但当前项目的事实、日历状态、权限和协作反馈都需要通过 Context 或工具提供，即，LLM 相当于 Agent 对大脑，用来分析和决策。

4.2 LLM 请求与响应协议

Agent 中实现 LLM 决策的方式，就是通过大模型 API 调用，因此必然涉及到相关的 LLM 协议，如：OpenAI Chat Completions/Responses 和 Anthropic Messages 协议。

LLM 协议同时规定请求和响应两端：

• 请求：把系统规则、用户目标、历史消息、工具定义和工具结果交给模型
• 响应：返回文本、结构化内容、工具调用、停止原因、用量或错误。

而 MCP、ACP 等协议位于更外层的连接，MCP 主要连接 Agent Host 与工具、资源和提示，ACP/A2A 等协议用于客户端或 Agent 之间的协作，这里暂不展开讨论

方向	典型内容	作用
请求（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 控制工具选择策略。我们仍用产品研讨会场景，一路跟进每次「请求→返回」。

第一轮调用：用户发起任务

用户发送“搜索竞品资料并整理成 PRD 结构。”后，Runtime 组装第一次请求。system 提供角色规则，user 是本轮目标，tools 声明可用工具，tool_choice: "auto" 允许模型自行决定是否调工具：

{
  "model": "gpt-5",
  "messages": [
    {"role": "system", "content": "你是产品研讨会助手，所有外部资料都要记录来源。"},
    {"role": "user", "content": "搜索竞品资料并整理成 PRD 结构。"}
  ],
  "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"
}

第一次返回：模型决定调用工具

模型认为需要先搜索，不直接输出文本，而是返回带 finish_reason: "tool_calls" 的响应，其中 assistant.tool_calls 给出了调用 ID、工具名和本次参数（要搜索“产品研讨会 竞品趋势”）：

{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {
      "id": "call_search_01",
      "type": "function",
      "function": {
        "name": "search_web",
        "arguments": "{\"query\": \"产品研讨会 竞品趋势\", \"time_range\": \"month\", \"max_results\": 10}"
      }
    }
  ],
  "finish_reason": "tool_calls"
}

第二轮调用：回填工具结果

Runtime 执行 search_web 拿到真实结果后，把本次的 tool_call 原样保留在 messages 里（代表模型的这一步动作），再追加一条 role: "tool" 消息，用 tool_call_id 关联回 call_search_01，把搜索结果交还给模型：

{
  "model": "gpt-5",
  "messages": [
    {"role": "system", "content": "你是产品研讨会助手，所有外部资料都要记录来源。"},
    {"role": "user", "content": "搜索竞品资料并整理成 PRD 结构。"},
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "id": "call_search_01",
          "type": "function",
          "function": {
            "name": "search_web",
            "arguments": "{\"query\": \"产品研讨会 竞品趋势\", \"time_range\": \"month\", \"max_results\": 10}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "tool_call_id": "call_search_01",
      "content": "搜索结果（共 3 个来源）：\n1.《2026 产品趋势报告》— 会议协作成为企业采购重点，来源 example.com/report\n2. 主流竞品 A 的官网，主打会议纪要自动归档，来源 example.com/compA\n3. PM 社区关于智能纪要选型的讨论帖，列出了 Top5 选型维度，来源 example.com/forum"
    }
  ],
  "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"
}

第二次返回：模型基于结果产出文本

模型拿到真实搜索结果后，finish_reason: "stop"，不再调用工具，开始组织 PRD 结构并给出正文：

{
  "role": "assistant",
  "content": "基于以下来源整理 PRD：\n\n1. 竞品 A 侧重于会议纪要与待办归档（来源：example.com/compA）\n2. 行业报告显示会议协作是企业采购重点（来源：example.com/report）\n3. 社区选型讨论归纳出 Top5 维度（来源：example.com/forum）\n\n建议聚焦「智能会议纪要 + 自动归档待办」场景，后续需补充：目标用户画像、核心流程与验收标准。",
  "finish_reason": "stop"
}

一轮任务就这样逐回合推进：模型选择动作并发出工具调用，Runtime 回填结果，模型再基于结果继续，直到 finish_reason: "stop" 收敛。Responses API 将同样的调用拆成 message、function_call、function_call_output 等事件，适合更细粒度的流式处理。

Anthropic Messages

Anthropic Messages API 把系统指令放在顶层 system，messages 主要承载用户和助手消息，工具定义使用 input_schema，工具调用和结果使用内容块。我们沿用同一个研讨会场景，逐层看每一次「请求→返回」。

第一轮调用：用户发起任务

与 Chat Completions 不同的是，system 在顶层，tools[].input_schema 描述参数，tool_choice: {"type": "auto"} 允许模型自主决定：

{
  "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"}
}

第一次返回：模型返回 tool_use 块

模型在 content 里返回一个 tool_use 块，携带调用 ID toolu_search_01 和参数，stop_reason: "tool_use" 表示接下来要执行工具：

{
  "stop_reason": "tool_use",
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_search_01",
      "name": "search_web",
      "input": {"query": "产品研讨会 竞品趋势", "max_results": 10}
    }
  ]
}

第二轮调用：回填 tool_result

Runtime 执行工具后，把上一步的 tool_use 块原样放回 messages，再以 user 角色携带一个 tool_result 内容块，用 tool_use_id 关联 toolu_search_01，并把搜索结果作为 content 交还：

{
  "model": "claude-sonnet",
  "max_tokens": 2048,
  "system": "你是产品研讨会助手，结论必须区分事实、假设和待验证问题。",
  "messages": [
    {"role": "user", "content": "搜索竞品资料并整理成 PRD 结构。"},
    {
      "role": "assistant",
      "content": [
        {
          "type": "tool_use",
          "id": "toolu_search_01",
          "name": "search_web",
          "input": {"query": "产品研讨会 竞品趋势", "max_results": 10}
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "tool_result",
          "tool_use_id": "toolu_search_01",
          "content": [
            {"type": "text", "text": "搜索结果（共 3 个来源）：\n1.《2026 产品趋势报告》— 会议协作成为企业采购重点\n2. 主流竞品 A，主打会议纪要自动归档\n3. PM 社区智能纪要选型讨论，归纳出 Top5 维度"}
          ]
        }
      ]
    }
  ],
  "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"}
}

第二次返回：模型基于结果产出文本

模型拿到搜索来源后，stop_reason: "end_turn"，开始整理 PRD 结构：

{
  "stop_reason": "end_turn",
  "content": [
    {
      "type": "text",
      "text": "基于检索到的来源，建议 PRD 聚焦「智能会议纪要 + 自动归档待办」：\n- 目标用户：研发与产品团队（来源：PM 社区讨论）\n- 核心能力：会议纪要、自动归档（来源：竞品 A）\n- 市场背景：会议协作是采购重点（来源：行业报告）\n后续需补充验收标准与评审排期。"
    }
  ]
}

Anthropic Messages 用 tool_use / 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 定义

LLM 能够决策的前提是，基于已有的先验知识和当前送入决策的上下文信息（之前的决策，返回的结果等），而承载这些信息的载体，就是 Context。

即，Context 是某个决策点实际送入模型、并会影响这次输出的信息集合。它来自 LLM 历史请求、工具输出等的多个部分，不能简单理解为“最近几轮聊天”。

以 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 设计成一张工作台：

• 稳定规则和工具定义放在固定前缀，便于缓存和复用。
• 当前目标、验收标准、状态摘要和待办放在动态区域。
• 搜索结果、文档片段和协作者反馈附带来源、时间和截断标记。
• 结构化记录已完成步骤、证据、假设、资料缺口和预算。
• 对独立调研任务使用独立上下文，主任务只接收结论与证据。
• 将用户指令、系统规则、工具观察和外部网页文本明确分层，外部文本按资料处理。

长任务中，完整历史保留过程，状态摘要负责表达当前进度，知识库保存可复用资料。三者的用途不同，混成一段长文本会降低检索和决策质量。

这里只做简单讲解，具体的 Context 组织和压缩方法不再本篇展开，目的是先建立起对 Agent 对基础认知。

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 会循环执行多次，因此应限制 Agent 执行的轮次、token、工具次数、时间和成本，并检测重复动作和无进展循环。

常见终止条件包括：

• 验收标准已满足且有证据支持
• 用户信息输入中断或主动暂停任务
• 缺少必要信息、达到 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	结果评估、反馈、修正	代码、文档、结构化产物	自评缺少证据、成本增加

先采用能覆盖任务的最小模式，再根据失败类型增加规划或检查。模式越多，状态、预算和可观测性要求越高。

参考资料

• OpenAI API 文档
• Anthropic API 文档
• Model Context Protocol
• Anthropic：Building effective agents
• OpenAI Agents SDK