设计有效的子代理
既然您已经知道如何创建子代理，接下来让我们看看能让它们真正发挥作用的模式。配置不当的子代理会漫无目的地运行、运行时间过长，或者产生主代理无法使用的输出。解决方法归结为四件事：编写良好的描述、定义输出格式、报告遇到的障碍，以及限制工具访问权限。
子代理配置数据是如何被使用的
当您向主上下文窗口代理发送消息时，每个可用子代理的名称和描述都会包含在系统提示中。这就是主代理决定启动哪个子代理以及何时启动的依据。如果您想更好地控制子代理何时被自动触发，名称和描述就是您应该调整的内容。
描述还承担着第二个作用。当主代理启动一个子代理时，它会编写一个输入提示来启动该任务。它会使用描述作为编写该提示的指导。因此，描述不仅控制子代理何时运行——它还塑造了子代理被告知要做什么。
编写能够塑造输入提示的描述
考虑一个代码审查子代理。如果描述很笼统，主代理可能会写出类似"使用 git diff 查找当前的更改"这样的输入提示。这很模糊。子代理必须自己弄清楚哪些文件是重要的。
如果您将描述更新为包含类似"您必须精确告诉代理您希望它审查哪些文件"的内容，主代理现在就会写出一个更具体的输入提示，列出实际需要审查的文件。
同样的技巧适用于不同类型的子代理。例如，在网络搜索子代理的描述中添加"返回可引用的来源"，会使主代理在委派任务时包含该指令。
定义输出格式
您可以对子代理做出的最重要的改进，就是在其系统提示中定义输出格式。这样做有两个作用：
- 它创建了自然的停止点——当子代理填完格式中的每个部分时，它就知道自己已经完成了。
- 它防止子代理运行时间过长。如果没有定义输出，子代理很难判断何时已经完成了足够的研究，往往会运行得比必要的时间长得多。
以下是代码审查子代理的结构化输出格式示例：
请以结构化格式提供您的审查：
- 摘要：您审查内容的简要概述和总体评估
- 严重问题：任何必须立即修复的安全漏洞、数据完整性风险或逻辑错误
- 主要问题：质量问题、架构不一致或重大性能问题
- 次要问题：风格不一致、文档缺失或小的优化点
- 建议：改进建议、重构机会或应应用的最佳实践
- 批准状态：明确说明代码是否可以合并/部署，或是否需要修改
这种格式为子代理提供了一个清晰的检查清单。一旦每个部分都填写完毕，子代理就知道可以停止了。
报告遇到的障碍
当子代理在工作过程中发现一个变通方法时——比如解决了一个依赖问题，或者发现某个命令需要特定的标志——这些细节需要出现在它返回的摘要中。如果没有出现，主线程就必须自己重新发现同样的解决方案，这会浪费时间和令牌。
您希望被呈现出来的信息类型包括：
- 设置问题或环境特殊情况
- 任务过程中发现的变通方法
- 需要特殊标志或配置的命令
- 导致问题的依赖项或导入
获取这些信息的方法是在输出格式中明确要求提供它。在输出模板中添加一个"遇到的障碍"部分，可以可靠地呈现这些信息。
- 遇到的障碍：报告审查过程中遇到的任何障碍。这可以是：设置问题、发现的变通方法或环境特殊情况。报告需要特殊标志或配置的命令。报告导致问题的依赖项或导入。
限制工具访问权限
并非每个子代理都需要访问每个工具。思考一下子代理实际需要做什么，只给它完成该工作所需的工具。这样做有两个作用：它可以防止意外的副作用，并且当您有多个子代理时，能让每个子代理的角色更加清晰。
以下是如何思考常见子代理类型的工具访问权限：
- 研究/只读子代理——只需要
Glob、Grep和Read。不会意外修改文件。 - 代码审查者——需要
Bash访问权限来运行git diff并查看发生了什么变化，但仍然不需要Edit或Write。 - 样式/代码修改代理——这是您应该授予
Edit和Write访问权限的地方，因为该子代理的工作就是实际修改您的代码。
整合所有内容
有效的子代理具有四个共同特征：
- 具体的描述——描述控制着子代理何时被启动以及它接收到什么指令。编写描述时要兼顾这两方面。
- 结构化输出——在系统提示中定义输出格式，这样子代理就知道自己何时完成，并返回主线程可以使用的信息。
- 障碍报告——在输出格式中包含一个部分，用于记录变通方法、特殊情况和问题，这样主线程就不必重新发现它们。
- 有限的工具访问权限——只给子代理实际需要的工具。研究用只读权限，审查者用 bash 权限，只有应该修改代码的代理才使用编辑/写入权限。
这些模式单独来看都很简单，但结合在一起，它们能将一个子代理从模糊地试图提供帮助的东西，转变为一个专注、可预测的工作者，能够按时完成任务并清晰地汇报结果。