什么是 AI Agent 开发

1. 先从场景出发

你有没有试过让 AI 帮你完成一件稍微复杂的事——比如先查最新资料，再写一篇带引用的技术文档，最后按团队格式改一版？

结果往往很分裂：它写得挺快，但引用的来源你对不上；格式看起来对，但术语和团队习惯不一致；你让它改一版，它又把前面已经确认好的结构打乱了。

这不是模型不够聪明。真正的问题是：我们把一个多步骤、多判断的任务，直接塞进了一次模型调用。模型只能看到当前 Prompt 里那点上下文，记不住之前确认过什么，也分不清“资料员”“作者”“编辑”该分别负责什么。

Agent 开发解决的就是这件事：不是让模型更聪明，而是给模型搭一个能执行、能检查、能复盘的工程环境。

简单讲：我们要为目标设计一个可执行的任务单元，让模型在受控的资料、工具、状态和输出约束下，按步骤完成工作，并留下可检查的过程证据。

2. 普通 LLM 应用和 Agent 应用，差别在哪

普通 LLM 应用像一条直路：

用户输入 -> Prompt -> 模型生成 -> 输出

Agent 应用把这条路拆成很多段。它不再指望一次模型调用包办全部工作，而是把目标拆成可执行、可检查、可回退的步骤：

用户目标
  -> 解析目标与约束（明确范围、受众、交付标准和不做事项）
  -> 召回相关上下文资料（项目文档、历史记录、既有约定）
  -> 检索外部信息（补齐过时、缺失或需要核验的事实）
  -> 规划任务结构（大纲、步骤顺序、关键判断点）
  -> 调用工具获取当前数据（API、数据库、搜索、脚本等）
  -> 生成中间产物（草稿、片段、候选方案）
  -> 按检查清单验证（事实、引用、格式、风格）
  -> 修订并记录状态（保留证据、版本和失败原因）
  -> 输出可交付版本（可审阅、可追溯的结果）

每一步都有明确的输入、输出和停下来检查的机会；前面已经确认的结论，不会在后面被悄悄改掉。 两者都用了 LLM，真正的差别在系统边界：

维度	普通 LLM 应用	Agent 应用
目标	生成一段回答或草稿	围绕目标完成一组可执行、可检查的步骤
上下文	主要来自当前输入和 Prompt	来自项目资料、历史记录、检索结果、工具返回和任务状态
工具	通常由业务代码固定调用	模型在约束内决定是否调用、调用哪个工具
状态	多数请求相互独立，做完即忘	保存步骤、证据、产物版本、审稿结果和失败原因
验证	依赖人工读完后判断	引入事实、引用、格式、风格检查，以及人工确认点

Prompt 只能装一部分规则。资料从哪来、工具怎么执行、中间状态如何保存、审稿如何独立进行，都需要在模型调用之外单独设计——这些才构成 Agent 应用真正的系统边界。

3. 为什么一个任务要拆给多个 Agent

复杂任务通常包含几类性质不同的工作：

• 目标解析：任务要服务谁，边界在哪里，什么算完成。
• 资料整理：哪些信息可信，哪些已过时，哪些判断还缺证据。
• 结构设计：先讲背景还是先给结论，证据如何组织，关键判断放在哪。
• 内容生成：把资料、判断和例子组织成可交付产物。
• 审稿验证：检查事实、引用、语气、结构和格式是否达标。

这些工作要的上下文不同，评价标准也不同。如果让同一个模型在一次调用里同时当研究员、作者、编辑和核查员，容易出两个问题：

1. 职责互相干扰：写作者追求顺畅完整，审稿者要对可疑判断保持敏感；两者混在一起时，模型更容易“写完就算过”。
2. 上下文被挤占：资料、草稿、规则、审稿清单堆进同一段上下文后，约束更容易被漏掉，前面已确认的结论也可能被悄悄改写。

所以多智能体的价值不是“Agent 越多越好”，而是职责边界清晰。先把每个角色的职责、输入、输出和通过标准定义清楚，再决定是一个人干完，还是多个人分工。

智能体	主要职责	典型输入	典型输出
目标解析	明确任务边界、约束和完成标准	用户目标、项目定位	任务说明、范围、不做事项
资料	召回并筛选可信资料	项目文档、历史记录、外部来源	资料卡片、证据列表、待核查点
规划	设计任务结构和执行顺序	目标、资料摘要	大纲、节点意图、关键判断
执行	生成或修改产物	大纲、资料、规则	草稿、修订版、代码片段
审稿	检查事实、结构、风格和格式	产物、资料、检查清单	问题清单、修改建议、通过/阻塞状态

这些角色不一定做成独立服务，也不一定每次都并行。边界清楚之后，多智能体从“数量更多”变成“责任更明确”：出了问题能定位到具体角色和产物，调试、回退和人工审稿也都能落到可检查的中间结果上。

4. 五个核心能力：让角色跑起来的基础设施

前面讲了角色分工，但角色不能凭空工作。就像一家公司需要会议室、文件柜、审批流和考勤系统，Agent 系统也需要五种底层能力来支撑这些角色。

能力	它让角色能做什么	如果不具备会怎样
上下文召回	让每个角色都看到该看的资料	角色只能凭记忆或旧知识做判断
工具调用	让角色接触外部世界	空谈多，拿不到真实数据
流程编排	决定角色按什么顺序上场、何时暂停	所有事堆在一起，互相干扰
任务状态	让长任务能暂停、恢复和交接	每次重启都要从头解释
审稿验证	把“完成”拆成可检查的条件	产物看起来对，实际上漏洞百出

这五种能力不是并列的。上下文召回和工具调用负责“输入”；流程编排和任务状态负责“执行过程”；审稿验证负责“输出质量”。下面逐个看。

4.1 上下文召回：先喂对资料

Agent 最容易失真的是信息来源。模型参数可能包含旧知识，用户给的材料也可能不完整。上下文召回负责回答三个问题：

1. 当前任务必须依赖哪些内部资料。
2. 哪些外部资料可以作为背景依据。
3. 哪些判断缺少证据，需要降级或删除。

资料来源通常包括：

来源	适用内容	常见实现
项目文档	产品边界、技术约束、内部术语	文件读取、全文检索、向量检索
历史记录	已有定义、风格偏好、避免重复	文档索引、标签检索
官方来源	API、框架能力、产品定义	Web 搜索、页面抓取、引用记录
用户输入	本次目标和特殊要求	任务说明、人工补充材料

召回出来的内容最好做成“资料卡片”，而不是塞进上下文的一大段文本。卡片里可以写清来源、要点、适用场景、可信度、是否需要引用、有没有时间敏感性。后续执行和审稿都能复用这些卡片。

4.2 工具调用：让模型伸手做事

模型本身不能读仓库、访问网页、运行命令。工具调用让 Agent 通过受控接口完成这些动作。

常见工具类型：

• 搜索工具：查找官方文档、论文、发布说明和项目资料。
• 文件工具：读取文档、配置、历史记录和术语表。
• 格式工具：运行格式化、检查语法、检查链接。
• 资料工具：把网页或文档整理成结构化资料卡片。
• 审稿工具：检查禁用词、引用缺失、重复段落、格式规范。

工具必须有边界。比如搜索工具优先访问可信来源；写文件工具只能修改当前任务允许的文件；格式化工具只对目标产物运行。缺少边界时，Agent 可能把局部问题扩大成不可控变更。

4.3 流程编排：决定谁先谁后、何时停

复杂任务可以写成明确的状态图。模型的自由判断主要发生在这些节点：资料够不够、产物怎么组织、审稿意见怎么处理。

接收任务
  -> 读取现有资料
  -> 上下文召回
  -> 生成结构
  -> 生成产物
  -> 审稿
  -> 是否存在阻塞问题？
      ├── 是 -> 修订产物 -> 再审稿
      └── 否 -> 格式化 -> 交付

能用固定流程解决的问题，不必全部交给完全自主的 Agent。更稳定的做法是“固定流程 + 局部自主”：

• 固定流程负责顺序、门禁和产物位置。
• Agent 负责在某个节点内判断资料是否够、该调用哪个工具、产物是否需要重写。
• 人工确认点放在关键判断、事实争议和最终发布前。

这样 Agent 的自由度集中在需要判断的环节，系统运行方式由流程和门禁控制。调试时也能判断问题来自资料不足、节点决策错误，还是工具结果没被正确使用。

4.4 任务状态：长任务的记事本

复杂任务经常跨越多轮。今天先做资料，明天再生成产物；审稿时发现资料不足，又回去召回。没有任务状态，Agent 每次都要重新理解上下文，错误也难定位。

一个 Agent 任务至少要保存这些状态：

状态	作用
任务目标	记录目标、范围、约束和交付要求
资料清单	记录已读资料、来源、适用场景和待核查点
结构版本	记录任务分解和每个节点要回答的问题
产物版本	记录每次生成和修订后的结果
审稿结果	记录问题、严重级别和处理状态
验证记录	记录格式化、检查、人工确认等动作

状态管理的作用是把中间结果留下来。失败后可以恢复，审稿时可以追溯，换一个 Agent 接手时也能知道当前进度。状态越清楚，审稿意见越容易转成下一轮修订动作。

4.5 审稿验证：质量的最后一道门

Agent 快速产出完整产物，容易让人误以为任务已经完成。真正可交付之前，还要看关键判断能否追溯、格式是否符合规则、审稿意见是否被处理。

审稿验证需要把“完成”拆成几类检查：

检查项	关注问题
事实检查	关键说法是否能回到资料来源，时间敏感信息是否已确认
结构检查	每个部分是否回答了设定的问题，前后是否有重复
风格检查	是否有空泛判断、强对立句、术语漂移或主持腔
格式检查	标题层级、链接、引用、语法是否符合项目规则
发布检查	元信息、索引、SEO、更新时间是否需要同步

审稿 Agent 最好输出可执行的问题清单，而不是笼统建议。例如：

P1: 第 3 节把多智能体写成必选方案，但前文没有限定任务复杂度。
建议：改成“先定义职责，再决定是否拆成多个 Agent”。

P2: 第 4 节提到某框架能力，但没有资料来源。
建议：补充官方文档来源，或删除该说法。

这种输出可以直接进入修订节点，也便于人工判断哪些问题必须处理。

5. 一个最小可用的项目长什么样

把前面的角色和能力合在一起，一个最小可用的 Agent 项目可以长这样：

用户提交任务
  -> 目标解析：明确范围和边界
  -> 资料召回：收集可信资料卡片
  -> 规划结构：生成大纲和关键判断
  -> 执行生成：产出初稿
  -> 审稿：输出问题清单
  -> 修订：按清单修改
  -> 交付检查：格式和引用确认
  -> 人工确认并交付

每个环节都有明确的输入和输出。资料不直接改产物，只给卡片；审稿不直接重写，只给问题；执行只负责按规则改。

这个流程跑起来之后，可以慢慢补：

• 引用追踪：产物中的关键判断能回到资料卡片。
• 版本对比：每次修订都能看到改了什么。
• 质量指标：记录审稿问题数量、返工次数、交付后修订次数。
• 偏好沉淀：把稳定的风格、禁用表达和规则整理成可复用配置。
• 失败分类：区分资料不足、工具失败、格式错误和判断越界。

这些能力会把任务执行从“一次性生成”逐步推向“可治理的流程”。治理的核心并不复杂：让资料、版本、审稿和验证都有记录，问题出现时能回到对应环节处理。

一句话总结

Agent 开发 = 在模型外面组织资料、工具、流程、状态和验证，让模型在约束下完成工作。