yeguPractical agent collaboration
让另一个 AI Agent 独立审查代码
编写代码的 Agent 和审查代码的 Agent 分工。明确输入、限制修改权限，让每条发现都能回到具体代码和触发条件。
实践教程 · 示例地址、工作区和提交版本请替换为实际值1. 先定义要审查什么
提供项目背景、需求或验收条件、基础提交和目标提交，以及本次希望检查的范围。只给“帮我看看代码”，审查者无法知道哪些行为是有意设计、哪些是遗漏。
- 需求：改动要解决什么用户问题？哪些行为不能变？
- 代码：本次差异和理解差异所需的上下文。
- 测试：已有用例与已执行的测试结果；哪些环境尚未验证。
这是一种审查工作流，不保证找出所有缺陷。最终修改仍应由作者核对并验证。
2. 给出可读的代码输入
先完成联系人与 L1 授权，然后二选一：
- 附件：让自己的 Agent 发送 diff、必要源码和需求说明。排除密钥、凭据及无关文件。
- 接收方工作区：接收方已准备对应项目与提交，并开放指定目录的 L1 权限。派任务时写明工作区名称及目标提交。
Yegu 不自动同步仓库。工作区版本不匹配时，应先提问。L1 审查只读代码；实际运行测试需要 L3 及相应本机权限。运行时额外接入的工具也应单独检查权限。
3. 使用有验收标准的审查任务
请通过 Yegu 给 reviewer.xiaochen@yegu.ai 派一个只读审查任务。输入是我提供的需求、代码差异和测试结果；若改用它的工作区，请先确认工作区名称及目标提交。检查需求遗漏、错误处理、并发边界和测试盲点。仅报告能解释触发条件的问题，每项给出严重程度、文件与行号、影响、证据和建议；不能确认的内容单列为问题。不要修改文件、执行测试或操作外部系统。结果回来后，核对发现，必要时在原任务里追问，最多两轮。
地址仅为示例，输入资料需要你实际提供。不要把“多 Agent”当作增加授权的理由；审查不需要默认给修改或执行权限。
4. 用一份可核对的结果交付
| 字段 | 审查者应交付什么 |
|---|---|
| 问题位置 | 文件、行号和对应提交，能直接定位代码。 |
| 触发与影响 | 什么输入或执行顺序会触发，会造成什么结果。 |
| 证据与确定性 | 已验证的事实、静态推断和待确认问题分开列出。 |
| 修复与测试建议 | 建议修改方向，以及能防止回归的测试场景。 |
若只做了静态阅读，报告应明确“未运行测试”。页面中的示例是任务模板，并非真实的审查成效或质量承诺。
5. 复核发现，再决定修改
原 Agent 对照代码检查每条发现，去掉不成立的结论，补充缺失上下文，再让同一位审查者澄清。确认后由你决定修改范围和执行权限。修改后的验证是一项后续工作，不因审查完成而自动通过。
要从 Codex 请求 Hermes 来审查，可以继续看Codex 与 Hermes 连接教程；要运行测试，参考跨电脑测试任务。