代理范围蔓延问题：为什么无限增长的 AI 代理会变得不可靠

Source: Dev.to

为什么会出现范围蔓延

代理很容易扩展。你添加一个工具，再添加另一个，新增一个 SOUL.md 规则，或者更宽泛的使命声明。每一次添加看似微小，但累计下来会导致代理出现冲突的优先级、上下文污染，以及没有明确的完成定义。

试图把所有事情都做好 的代理往往是 那个根本无法可靠完成任何任务的代理。

会出现什么问题

• 冲突的约束 – 一个被要求“提供帮助”又“在预算上保持保守”的代理会在不同情境下选择其一，而你在出现故障之前根本不知道它选择了哪一个。
• 上下文污染 – 过宽的任务会加载更多无关的上下文，稀释代理做出正确决策所需的信号。
• 所有权不明确 – 当代理的范围与其他系统的职责重叠时，会出现竞争条件、重复操作以及静默覆盖。
• 没有有效的“完成”状态 – 如果代理的工作模糊不清，它永远无法验证是否已完成。于是它要么一直运行，要么随意停止。

单一职责规则

可靠系统中的每个代理只做一件事，其余的全部交给其他代理。

## My Job
I am the research agent. I find, summarize, and validate information.
I do NOT send emails, update files outside /research/, or make purchases.
When I finish a task, I write output to outbox.json and stop.

最后一句很关键。明确的停止条件会把一个开放式的代理转变为可预测的系统组件。

如何审查范围蔓延

自问：

• 我能用一句话描述这个代理的功能吗？
• 我能列出它明确不会做的三件事吗？
• 它是否有清晰的输出格式和停止条件？

如果这三点中有任何一项答不上来，说明范围过于宽泛。

交接模式作为解决方案

与其让一个代理承担更多任务，不如使用交接模式：

{
  "task_complete": true,
  "output_location": "/research/summary-2026-03-09.json",
  "next_agent": "kai",
  "instruction": "Review research summary and update project tracker"
}

每个代理只完成自己的单一任务，然后把“接力棒”交给下一个。系统保持模块化、可审计且易于修复。

复合收益

当代理的范围严格受限时：

• 故障被隔离（只有单个代理出错，而不是整个系统）
• 调试更快（你清楚该去哪里查找问题）
• 改进呈叠加效应（更紧的范围 = 更一致的训练信号，便于细化）

运行可靠多代理系统的团队并不是在使用一个强大的代理，而是使用许多职责单一的代理。

完整的单一职责代理设计模式库——包括 SOUL.md 模板和交接模式 schema——请访问 askpatrick.co。