上周，我让一个多Agent系统帮我分析GitHub项目，结果它二话不说就创建了5个子任务，忙活半天给出一堆数据，却没能回答我最核心的问题——这个项目到底值不值得学习？
这让我想起Andrej Karpathy之前那篇火遍开发者圈的吐槽。他精准指出了LLM编程的几个通病：模型会默默做出错误假设然后执行，喜欢过度复杂化代码，甚至擅自修改无关内容。这跟我那次失败的多Agent任务简直一模一样。
于是我做了一个实验：将Karpathy总结的四大编程原则，迁移应用到多Agent编排（Harness Agent）的场景中。结果出乎意料地好。
Karpathy四大原则回顾
在进入迁移实践前，先快速回顾一下这四条每个AI编程者都该记住的原则：
🤔 先思考再编码 (Think Before Coding)
解决的问题：LLM经常默默选择一个解释然后执行，不问问题。
核心实践：显式声明假设；遇到歧义时先澄清；必要时提出异议。
🎯 简洁优先 (Simplicity First)
解决的问题：过度工程化，100行能解决的搞成1000行。
核心实践：不添加请求之外的功能；不为单次使用创建抽象；如果200行能变50行，就重写它。
🔪 手术式修改 (Surgical Changes)
解决的问题：擅自修改无关的代码、注释或格式。
核心实践：只修改必须修改的；不“改进”相邻代码；匹配现有风格。
✅ 目标驱动执行 (Goal-Driven Execution)
解决的问题：模糊的成功标准（比如“让它工作就行”）。
核心实践：将命令式任务转为可验证的目标；采用测试驱动开发思路；明确关键检查点。
当Karpathy原则遇上Harness Agent
Harness Agent，简单说就是多Agent系统的“总指挥”，负责任务分解、资源调度和结果聚合。它的核心理念是“编排而非执行”。
但问题在于，很多Harness Agent的实现方式，恰恰落入了Karpathy所描述的那些陷阱。下面就是我将这四大原则迁移到多Agent编排场景的具体实践。
原则一迁移：先思考再分发 (Think Before Dispatching)
常见翻车现场
用户：帮我分析这个 GitHub 项目
❌ 错误做法：
→ 立即创建 5 个子任务（代码、文档、趋势、社区、竞品）
→ 2 小时后给出一堆数据，但没回答核心问题
问题在于，Harness Agent跳过了最关键的一步：澄清需求。“分析”到底指什么？是技术架构、社区活跃度，还是“值不值得学”的决策建议？
正确做法
用户：帮我分析这个 GitHub 项目
✅ 正确做法：
→ 先反问：
- “分析”具体指什么维度？
- 你的身份是什么？（开发者学习？投资人评估？）
- 需要多深？（概览还是深度？）
- 什么时候要？（时间约束？）
→ 得到澄清后，再决定是否需要多 Agent 协作
分发前自查清单
□ 需求澄清了吗？有歧义吗？
□ 我的假设是什么？正确吗？
□ 真的需要多 Agent 吗？单个 Agent 能完成吗？
核心洞察：多Agent不是炫技，而是解决问题的手段。能用一个Agent搞定，就别搞三个。这也是构建高效人工智能工作流的基础。
原则二迁移：最简编排 (Simplest Orchestration)
常见翻车现场
任务：写一封邮件
错误做法：
→ 创建：草稿 Agent + 语气检查 Agent + 语法检查 Agent + 格式优化 Agent
→ 4 个子任务，3 次协调，2 轮合并
→ 最后生成的邮件和普通 Agent 写的没区别
问题：典型的过度设计，为不存在的复杂度买单。
正确做法
任务：写一封邮件
✅ 正确做法：
→ 单个 Agent 完成
→ 必要时人工请求修改
→ 1 个任务，0 次协调
编排方案自查清单
□ 这是最简单的编排方案吗？
□ 能减少几个子任务吗？
□ 我在为“可能有用”的场景设计吗？
判断标准很直观：如果一位资深工程师看了你的设计说“这太复杂了”，那就立刻简化。
原则三迁移：手术式分发 (Surgical Dispatching)
核心原则映射：只分发必须分发的任务，只清理自己制造的混乱。
映射到Harness Agent，你需要明确：
□ 每个子任务的职责边界明确吗？
□ 子任务会越界修改其他任务的输出吗？
□ 风格要求明确吗？（匹配现有格式/语气）
子任务描述模板
我使用以下模板来严格定义每个子任务，关键在于明确“边界”和“不做什么”。
## 子任务：[名称]
**职责**: [一句话描述做什么]
**输入**: [依赖哪些前置输出]
**输出**: [具体交付物格式]
**边界**: [明确不做什么]
**风格**: [匹配现有 XXX 的格式/语气]
**成功标准**: [可验证的检查点]
原则四迁移：目标驱动编排 (Goal-Driven Orchestration)
常见翻车现场
任务：“分析这个项目”
❌ 模糊标准：
→ 什么叫“分析”？什么叫“完成”？
→ 最后发现方向错了，但已经做了 2 小时
正确做法
任务：“分析这个项目”
✅ 可验证目标：
→ 输出包含：Star 趋势、主要贡献者、技术栈、最近 10 个 Issue 分类
→ 每个维度有具体数据支撑
→ 给出“值不值得学习”的明确建议和理由
多步骤任务计划模板
## 执行计划
1. **[子任务 1]** → 验证：[具体检查点]
2. **[子任务 2]** → 验证：[具体检查点]
3. **[结果聚合]** → 验证：[完整性检查]
4. **[质量审查]** → 验证：[验收标准]
核心洞察：强的、可验证的成功标准能让Agent自主运行。弱的标准（如“让它工作”）则会导致需要不断人工澄清。
完整实战示例：撰写小红书AI编程分析报告
场景：用户请求“帮我研究小红书AI编程话题，写一篇分析报告”。
❌ 错误做法（违反所有原则）
立即创建 5 个子任务：搜索Agent、爬取Agent、分析Agent、写作Agent、审核Agent。
问题：没有澄清需求、过度设计、缺少验收标准。
✅ 正确做法（融合四大原则）
Step 1: 先思考再分发
先反问澄清：报告用途？目标读者？分析深度？时间约束？
Step 2: 最简编排
采用最简方案：
- 研究Agent：负责搜索 + 数据收集 + 初步分析
- 写作Agent：负责报告撰写
而非复杂的5个Agent流程。
Step 3: 手术式分发
为每个子任务明确边界：
### 子任务 1：数据研究
- **职责**: 收集小红书 AI 编程话题数据
- **输入**: 关键词列表
- **输出**: JSON 格式数据（笔记标题、点赞、评论、核心观点）
- **边界**: 不做分析，只收集
- **数量**: 30-50 条高互动笔记
### 子任务 2：报告撰写
- **职责**: 基于数据撰写分析报告
- **输入**: 研究 Agent 的 JSON 输出
- **输出**: Markdown 格式报告
- **风格**: 匹配公众号文章风格
- **结构**: 按指定模板（背景、发现、洞察、建议）
Step 4: 目标驱动编排
设定清晰的验收标准：
### 验收标准
**研究阶段**：
- [ ] 收集至少 30 条笔记
- [ ] 每条笔记包含：标题、点赞数、核心观点
- [ ] 覆盖至少 5 个不同子话题
**写作阶段**：
- [ ] 报告包含 4 个章节
- [ ] 每章有数据支撑
- [ ] 总字数 3000-5000 字
- [ ] 包含可执行的洞察和建议
**时间节点**：
- T+30min: 研究完成
- T+60min: 初稿完成
- T+75min: 最终审核
一份即用的Harness Agent检查清单
我把这套方法浓缩成一张检查卡，建议你在每次使用多Agent系统前快速过一遍：
┌─────────────────────────────────────────────────────────────┐
│ Harness Agent - 任务分发检查卡 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🤔 Think Before Dispatching │
│ □ 需求澄清了吗？有歧义吗？ │
│ □ 我的假设是什么？正确吗？ │
│ □ 真的需要多 Agent 吗？ │
│ │
│ 🎯 Simplicity First │
│ □ 这是最简单的编排方案吗？ │
│ □ 能减少几个子任务吗？ │
│ □ 我在过度设计吗？ │
│ │
│ 🔪 Surgical Dispatching │
│ □ 每个子任务边界清晰吗？ │
│ □ 会越界修改其他输出吗？ │
│ □ 风格要求明确吗？ │
│ │
│ ✅ Goal-Driven Orchestration │
│ □ 成功标准可验证吗？ │
│ □ 有中间检查点吗？ │
│ □ 验收条件具体吗？ │
│ │
└─────────────────────────────────────────────────────────────┘
为什么这套方法有效？
底层逻辑是相通的：LLM的固有缺陷不会因为使用了多Agent而消失，反而可能被放大。单个Agent会过度工程化？多个Agent协作时情况可能更糟。单个Agent不问问题？那么作为“总指挥”的Harness Agent不问问题，就会导致整个团队跑偏。
因此，多Agent系统需要的不是更弱，而是更强的元认知和过程管理能力。这套方法正是提供了这样的框架。
写在最后
折腾AI编程的实践经验告诉我：工具越来越强大，但使用工具的“心法”往往更重要。
Karpathy的原则不是束缚创造力的条条框框，而是避免常见陷阱的护栏；Harness Agent的理念也不是为了炫技，而是让多个AI智能体能高效协作的框架。当这两者结合，我们最终得到的不是更复杂的系统，而是更靠谱、更高效的结果。
希望这份基于实战的思考，能帮助你在构建多Agent工作流时少走弯路。欢迎在云栈社区交流你的实践心得。
发表于 1 小时前
|
查看: 2|
回复: 0
