Agent 实践与治理（Agent Practice）

上一章，我们了解了 Agent 的内部机制。这一章，我们来看怎么用好 Agent：配置、治理、以及常见的陷阱。

配置与治理：Rules 和 Skills

Rules：行为准则

Rules 是你给 Agent 设定的行为准则。它定义了“什么该做、什么不该做、怎么做”。

比如：

代码风格：使用 2 空格缩进，使用单引号。
提交规范：commit message 使用英文，格式为 type(scope): description。
安全要求：不要硬编码任何密钥或密码。

Rules 的价值在于一致性。没有 Rules，Agent 每次可能用不同的风格写代码、用不同的格式写提交信息。有了 Rules，输出会稳定得多。

你可以先让 Agent 自由发挥，观察它的输出，然后把你不满意的地方写成 Rules。这样 Rules 是从实际问题中长出来的，而不是凭空想象的。

Skills：可复用的能力

Skills 是 Agent 的可复用能力模块。一个 Skill 通常是一个“指令 + 工具调用”的组合。

比如：

• “代码审查” Skill：读取代码 → 检查风格 → 检查安全 → 输出报告。
• “文档生成” Skill：读取代码 → 提取注释 → 生成文档。
• “测试编写” Skill：读取函数 → 分析边界 → 生成测试用例。

Skills 的价值在于复用。你不需要每次都从零开始描述需求，调用一个 Skill 就行。

没有 Skills：每次都要写详细的需求描述
有了 Skills：调用 skill name，Agent 自动执行预定义流程

但 Skill 不能写得太抽象。比如“帮我写好文章”很难执行，“先整理主题、再列 5 个小标题、每节写 120 字、最后检查是否有重复观点”就清楚得多。

写 Skill 时，可以把它当作一份小型操作手册：

• 什么时候使用这个 Skill。
• 输入需要包含哪些信息。
• 按什么步骤执行。
• 每一步怎么判断是否完成。
• 失败时停在哪里，向用户说明什么。

具体的 Skill 才能复用。抽象的 Skill 看起来高级，实际执行时往往只是把不确定性藏起来。

指令层级：SOUL.md → AGENTS.md → Rules → Prompt

当你的 Agent 使用场景变多时，指令会分层。理解这个层级，能帮你更好地组织和管理 Agent 的行为。

从上到下：

SOUL.md：系统人格

SOUL.md 定义了 Agent 的“人格”：它的角色、价值观、行为风格。

你是一个专业的代码审查员。你注重代码质量、安全性和可维护性。
你不会为了讨好用户而忽略问题。你会直接指出问题，但语气保持尊重。

这是最高层级的指令，影响 Agent 的所有行为。

AGENTS.md：Agent 定义

AGENTS.md 定义了具体 Agent 的能力和职责。

你有以下能力：
- 读取和分析代码
- 执行测试
- 生成报告

你的职责是：
- 检查代码质量和安全问题
- 运行测试并报告结果
- 不要修改代码，只报告问题

Rules：行为规则

上一节讲的 Rules，在这个层级生效。它们是具体的、可执行的行为准则。

Prompt：具体任务

最底层是你每次给出的具体任务指令。

请审查 src/utils.js 这个文件。

这个层级结构要记住一件事：上层指令约束下层指令。如果 Prompt 和 Rules 冲突，Rules 优先；如果 Rules 和 SOUL.md 冲突，SOUL.md 优先。

SOUL.md：你不会为了讨好用户而忽略问题
  ↓ 约束
AGENTS.md：你的职责是检查代码质量
  ↓ 约束
Rules：代码风格使用 2 空格缩进
  ↓ 约束
Prompt：请审查 src/utils.js

Multi-agent：正确打开方式

当你熟练使用单个 Agent 之后，很自然会想：能不能用多个 Agent 协作？

答案是：可以，但不一定是好主意。

Multi-agent 适合的场景

• 任务有明确的分工：比如一个 Agent 负责写代码，另一个负责审查。
• 需要不同视角：比如一个 Agent 从用户角度思考，另一个从安全角度思考。
• 任务可以并行：比如同时处理多个独立的子任务。

Multi-agent 不适合的场景

• 任务本身很简单：一个 Agent 就能搞定的事，拆成多个 Agent 只会增加协调成本。
• Agent 之间需要频繁通信：如果 Agent A 的输出是 Agent B 的输入，而 B 的输出又是 A 的输入，这种循环依赖会让系统变得脆弱。
• 你还没有用好单个 Agent：如果单个 Agent 的 Prompt 都写不好，多个 Agent 只会把问题放大。

一个常见的误区：觉得 Multi-agent = 更高的效率。实际上，Multi-agent 往往只是更复杂的系统。它带来了新的问题：

• 协调成本：谁先执行？谁后执行？结果怎么合并？
• 错误传播：一个 Agent 的错误可能影响整个链条。
• 调试困难：出了问题，是哪个 Agent 的错？

正确做法：先用单个 Agent 把事情做好。只有当单个 Agent 确实搞不定时，才考虑拆分。而且拆分时，优先考虑最简单的方案：两个 Agent 串行执行，而不是多 Agent 编排。

Multi-agent 的实现模式

如果你确实需要多个 Agent 协作，有几种常见的编排模式：

顺序模式（Sequential）

最简单的方式：Agent A 做完 → 结果传给 Agent B → Agent B 做完 → 结果传给 Agent C。

任务 → [Agent A: 分析] → [Agent B: 执行] → [Agent C: 审查] → 结果

适合有明确先后依赖的任务。比如：先让分析 Agent 拆解需求，再让编码 Agent 实现，最后让审查 Agent 检查。

并行模式（Parallel）

多个 Agent 同时执行独立的子任务，最后合并结果。

         ┌→ [Agent A: 查文档] ─┐
任务 →  ├→ [Agent B: 跑测试] ─├→ 合并 → 结果
         └→ [Agent C: 分析日志] ┘

适合子任务之间没有依赖的场景。比如同时从三个数据源拉取信息。

辩论模式（Debate）

多个 Agent 对同一个问题给出不同观点，由一个裁判 Agent 选择最佳答案。

         ┌→ [Agent A: 观点 1] ─┐
问题 →  ├→ [Agent B: 观点 2] ─├→ [裁判 Agent: 综合判断] → 结论
         └→ [Agent C: 观点 3] ┘

适合需要多角度思考的决策场景。不同 Agent 可以有不同的“人设”（比如乐观派、悲观派、务实派），从不同角度看同一个问题。

分层模式（Hierarchical）

一个“管理者” Agent 负责拆解任务和分配，多个“执行者” Agent 负责具体执行。

任务 → [管理者 Agent]
           ├→ 分配子任务 1 → [执行者 A]
           ├→ 分配子任务 2 → [执行者 B]
           └→ 汇总结果 → 最终输出

适合复杂任务的动态拆分。管理者 Agent 根据任务特点决定派谁去做。

模式怎么选？

• 能用顺序就用顺序：最简单，最容易调试。
• 需要速度且任务独立时用并行。
• 需要多角度决策时用辩论。
• 任务无法预先定义流程时用分层。

不要为了“看起来高级”而选复杂的模式。能用两个 Agent 串行解决的，就不要搞四个 Agent 并行加辩论。

M×N Gateway：企业级 Agent 集成

在企业场景下，你可能面对的是：M 个应用需要调用 N 个模型。如果每个应用都直接对接每个模型，就是 M×N 条连接：维护成本极高。

M×N Gateway 的思路是：加一个中间层。

没有 Gateway：应用1→模型1, 应用1→模型2, 应用2→模型1, 应用2→模型2  (M×N)
有了 Gateway：应用1→Gateway→模型1/模型2, 应用2→Gateway→模型1/模型2  (M+N)

Gateway 的价值：

• 统一管理：在一个地方控制所有模型的访问权限、用量、计费。
• 灵活切换：换了模型提供商，只需要改 Gateway 配置，不需要改每个应用。
• 负载均衡：根据任务类型自动选择最合适的模型。

对个人学习者来说，这个概念了解即可。但如果你未来在企业环境中使用 Agent，Gateway 会是一个常见的架构模式。

评估与调试

怎么知道你的 Agent 做得好不好？怎么在它出问题时找到原因？

评估结果的有效性

AI 的输出看起来“像那么回事”，但不一定对。你需要一套方法来验证。

事实核查：AI 给出的信息是否准确？最直接的方法是让它给出来源，然后你去核实。如果它给不出来源，那这个信息的可信度就要打折扣。

一致性检查：用不同的方式问同一个问题，看答案是否一致。如果两次回答矛盾，至少有一个是错的。

第一次：用 Python 怎么读取 CSV 文件？
第二次：用 Python 读取 CSV 文件有哪些方法？

如果第一次它说“用 pandas”，第二次说“用 csv 模块”，两个都对。但如果第一次说“用 open() 直接读”，第二次说“必须用 pandas”，就有问题了。

边界测试：给 AI 一些极端情况，看它的回答是否合理。

如果数组长度是 0 会怎样？
如果用户输入的是空字符串呢？
如果网络请求超时了呢？

AI 在正常情况下可能回答得很好，但遇到边界情况就可能出错或“编”出不存在的处理逻辑。

对抗性测试：故意给错误的前提，看 AI 是否会纠正你还是顺着你说。

Python 的 list 是不可变的，对吧？

如果 AI 说“对”，那它的可靠性就值得怀疑。（Python 的 list 是可变的。）

构建任务样本

如果你会反复使用同一个 Agent，不要只凭一次感觉判断它好不好。准备一小组固定任务样本，每次改 Rules、Skill、工具或模型后，都用这组样本重新跑一遍。

任务样本不需要很大，初学阶段 5 到 10 个就够。关键是覆盖常见情况和容易出错的情况：

• 正常任务：它应该顺利完成。
• 边界任务：输入为空、信息不完整、格式不规范。
• 对抗任务：用户给出错误前提，看看它会不会纠正。
• 高风险任务：涉及删除、发送、发布、支付等副作用时，必须触发确认。

每个样本都要写清楚验收标准。比如“必须列出来源”“不能修改文件”“测试失败时不能声称完成”。标准越清楚，评估越不容易变成主观感觉。

这样你就有了一个小型回归检查。它不保证 Agent 永远正确，但能防止你改了一个地方，悄悄弄坏另一个地方。

避免幻觉的系统性方法

前面几章零散提过幻觉问题，这里做一个系统性的总结。

给明确的依据：不要让 AI “凭记忆”回答，而是给它具体的文档、代码、数据。

不要问：Python 的 sort 函数时间复杂度是多少？
而是问：根据 Python 官方文档（附上文档内容），sort 函数的时间复杂度是多少？

要求标注不确定性：在 Prompt 中明确要求 AI 在不确定时说“我不确定”，而不是编一个答案。

如果你不确定，请明确说“我不确定”或“需要进一步验证”。不要猜测。

交叉验证：让 AI 给出结论后，要求它提供支持这个结论的证据或引用。如果它给不出，结论就不可靠。

分步验证：不要让 AI 一口气做完所有事情。每做完一步，验证一步。这样即使出错，也能立刻发现并纠正。

追踪 Agent 的执行过程

当 Agent 的执行变得复杂时，你需要能“看到”它在做什么。

日志记录：在 Agent 的每个主要步骤记录日志：它调用了什么工具、传了什么参数、得到了什么结果。

[14:23:01] 调用工具: read_file({ path: "config.json" })
[14:23:01] 返回结果: { "timeout": 30, "retries": 3 }
[14:23:02] 决策: 需要修改 timeout 值
[14:23:02] 调用工具: write_file({ path: "config.json", content: "..." })

中间结果检查：在 Agent 的 Loop 中，定期暂停，检查中间结果是否符合预期。这比等它跑完再检查效率高得多。

回放与重放：记录 Agent 的完整执行过程（包括每一步的输入和输出），出问题时可以回放，定位是哪一步出了错。

人工抽样：即使 Agent 跑得很顺，也要定期人工抽查结果。AI 可能在大部分情况下是对的，但偶尔的错误如果没人发现，后果可能很严重。

评估的几个层次

1. 单次输出评估：这一次回答对不对？有没有幻觉？
2. 流程评估：Agent 的执行路径是否合理？有没有不必要的步骤？
3. 结果评估：最终产出是否满足用户需求？质量如何？
4. 效率评估：花了多少 Token？用了多少时间？成本是否可控？

对学习者来说，先做好第一层（单次输出评估）就够了。后面三层是进阶内容。

安全与运行检查

Agent 一旦能调用工具，就要把它当作会执行操作的系统来看，而不是只会聊天的模型。

上线或长期使用前，至少检查几件事：

• 权限：它能读什么、写什么、删除什么？默认权限要保守。
• 确认点：发送邮件、发布内容、删除文件、付款、改生产数据之前，必须有人确认。
• 可观察性：它每一步调用了什么工具、传了什么参数、得到什么结果，应该能被回看。
• 成本与延迟：最长跑多久？最多花多少 Token？超过限制后怎么停下来？
• 失败处理：工具报错、网络超时、信息不足时，是重试、降级，还是停止并说明原因？
• 敏感信息：密钥、隐私数据、公司机密是否会进入 Prompt、日志或长期记忆？

可以把 Agent 的安全目标压成三句话：人能控制它，它的权限有限，它做过什么能被看见。

案例练习

以下是几个真实场景，供你练习和探索。每个场景都没有标准答案，练习时重点看你怎么拆解和处理。

场景一：会议纪要自动化

你有一段会议录音，需要整理成结构化的会议纪要，并提取待办事项。

思考方向：

• 你需要哪些工具？（语音转文字、文本分析、文件写入）
• 怎么设计 Agent 的 Loop？
• 哪些步骤需要人工确认？

场景二：代码审查流程

你希望 Agent 自动审查 Pull Request 中的代码变更。

思考方向：

• Agent 需要读取什么信息？（代码差异、项目规范、历史 PR）
• 怎么让 Agent 给出有价值的审查意见，而不是泛泛而谈？
• 审查结果怎么呈现？

场景三：数据报告生成

每天需要从数据库提取数据，生成日报，发送到团队群。

思考方向：

• 这个任务适合用 Agent 还是用传统的自动化脚本？
• 如果用 Agent，它的 Loop 该怎么设计？
• 出错了怎么办？（数据异常、发送失败）

场景四：设计稿到代码

设计师给了一个 Figma 文件，你需要把它变成可运行的前端代码。

思考方向：

• Agent 需要理解 Figma 的什么信息？（布局、颜色、字体、间距）
• 生成的代码怎么保证和设计稿一致？
• 响应式适配怎么做？

反模式汇总

前面几章分散讲了一些反模式，这里做一个集中回顾。

Prompt 层面

反模式	问题	正确做法
Context Bloat	塞太多上下文，AI 注意力被稀释	只给必要信息，复杂信息先摘要
Mega-Prompt	一条 Prompt 做所有事	拆成多步，每步只做一件事
忽视迭代	期望一条 Prompt 就完美	把第一轮当起点，多轮对齐

思维层面

反模式	问题	正确做法
确认偏误	AI 倾向同意你	主动要求反驳，换角度提问
盲目信任	不验证 AI 的输出	高风险节点必须人工校验
模型崇拜	只看排行榜选工具	顺手可用比排名重要

AI Coding 层面

反模式	问题	正确做法
忽略架构	能跑就行，不管可维护性	先画蓝图，再砌砖
上下文爆炸	项目大了 AI 失去全局视角	保持代码结构清晰，用文档记录
安全后置	出事了才考虑安全	从一开始就考虑安全

Agent 层面

反模式	问题	正确做法
过早 Multi-agent	协调成本 > 收益	先用好一个 Agent
过度工程化	为了使用而使用	够用就行，不追复杂
权限过大	Agent 能做太多事	最小权限，渐进信任
抽象 Skill	规则太空泛，执行时各做各的	写清输入、步骤、完成标准
无回归样本	改完不知道有没有退化	保留一组固定任务样本

小结

• Rules 和 Skills 是 Agent 治理的基础。Rules 保证一致性，Skills 提升效率。
• Skill 要具体，不要抽象；它应该像操作手册，而不是口号。
• 指令层级：SOUL.md → AGENTS.md → Rules → Prompt，上层约束下层。
• Multi-agent 不一定能提升效率：先用好一个 Agent，再考虑多个。实现模式有顺序、并行、辩论、分层四种。
• 验证 AI 输出的方法：事实核查、一致性检查、边界测试、对抗性测试。
• 避免幻觉：给明确依据、要求标注不确定性、交叉验证、分步验证。
• 评估要留下任务样本，执行要留下日志，高风险操作要留下确认点。
• 反模式遍布各个层面：知道什么不该做，和知道什么该做同样重要。

练习

1. 为你正在使用的 AI 工具写一份 Rules 文件（3-5 条规则），观察它对输出一致性的影响。
2. 设计一个指令层级：写一个 SOUL.md（定义角色）、一个 AGENTS.md（定义能力）、3 条 Rules（定义规则），然后用它们指导 Agent 执行一个任务。
3. 把一个你常做的任务写成 Skill：说明输入、步骤、完成标准和失败时的处理方式。
4. 从上面的案例练习中选一个场景，画出 Agent 的工作流程图（包括 Loop、工具调用、人工确认节点）。
5. 为这个场景设计 5 个任务样本，至少包含 1 个正常任务、1 个边界任务和 1 个高风险任务。

延伸阅读

• RAG 技术详解：向量检索与混合搜索
• 同步与异步 Sync & Async
• 进程与线程 Process & Thread
• 事务 Transaction