写在前面：这是我在折腾 OpenClaw 多 Agent 协作时的深度思考。如果你也在用 AI 编程、搭建智能体，这篇文章可能会帮你少走很多弯路。

01 一个真实的翻车现场上周，我让 OpenClaw 帮我分析一个 GitHub 项目。结果它二话不说，直接创建了 5 个子任务：代码分析、文档分析、趋势分析、社区分析、竞品分析……最后确实给了我一堆数据，但我真正想知道的——“这个项目值不值得学习”——反而没说清楚。典型的"用战术勤奋掩盖战略懒惰"。这让我想起 Andrej Karpathy 前段时间那条爆火的推文。他吐槽 LLM 编程的几大坑：“模型会替你做出错误假设，然后默默执行。它们不管理自己的困惑，不寻求澄清，不呈现权衡分析。”"

它们喜欢过度复杂化代码，100 行能解决的事情非要搞 1000 行。""它们甚至会修改/删除自己看不懂的注释和代码，即使那些跟任务完全无关。"这不就是我那个翻车的多 Agent 任务吗？于是我做了一件事：把 Karpathy 的四大编程原则，迁移到 Harness Agent（多 Agent 编排）场景。结果出乎意料的好。02 Karpathy 四大原则原貌先快速过一下 Karpathy 的原版原则（强烈建议每个 AI 编程实践者刻在脑子里）：🤔 Think Before Coding - 先思考再编码解决的问题：LLM 经常默默选择一个解释然后执行，不问问题。

实践：• 显式声明假设• 有歧义时先澄清• 必要时提出异议 Simplicity First - 简洁优先解决的问题：过度工程化，100 行能解决的搞成 1000 行。实践：• 不添加请求之外的功能• 不为单次使用创建抽象• 如果 200 行能变 50 行，重写它 Surgical Changes - 手术式修改解决的问题：修改无关代码、注释、格式。实践：• 只修改必须修改的• 不"改进"相邻代码• 匹配现有风格 Goal-Driven Execution - 目标驱动执行解决的问题：模糊的成功标准（“让它工作”）。

实践：• 将命令式任务转为可验证目标• 写测试驱动开发• 明确检查点03 当 Karpathy 遇上 Harness AgentHarness Agent 是什么？简单说，它是多 Agent 系统的元控制器，负责任务分解、资源调度、结果聚合。

它的核心哲学是：“Orchestrate, Don’t Execute”（编排而非执行）。但问题是，很多 Harness Agent 实现（包括我之前的用法）都掉进了 Karpathy 描述的那些坑。下面是我的原则迁移实践：原则 1 迁移：Think Before Dispatching原原则：Think Before Coding（先思考再编码）迁移后：Think Before Dispatching（先思考再分发）常见翻车场景

用户：帮我分析这个 GitHub 项目

❌ 错误做法：
→ 立即创建 5 个子任务（代码、文档、趋势、社区、竞品）
→ 2 小时后给出一堆数据，但没回答核心问题问题在哪？Harness Agent 没做最重要的事：澄清需求。"分析"具体指什么？• 技术架构分析？• 社区活跃度评估？• 代码质量审查？• 还是"值不值得学习"的决策建议？正确做法

用户：帮我分析这个 GitHub 项目

✅ 正确做法：
→ 先反问：

• "分析"具体指什么维度？
• 你的身份是什么？（开发者学习？投资人评估？）
• 需要多深？（概览还是深度？）
• 什么时候要？（时间约束？）

→ 得到澄清后，再决定是否需要多 Agent 协作检查清单每次分发任务前，Harness Agent 应该自问：

□ 需求澄清了吗？有歧义吗？
□ 我的假设是什么？正确吗？
□ 真的需要多 Agent 吗？单个 Agent 能完成吗？核心洞察：多 Agent 不是炫技，是解决问题的手段。能用一个 Agent 搞定，就别搞三个。原则 2 迁移：Simplest Orchestration原原则：Simplicity First（简洁优先）迁移后：Simplest Orchestration（最简编排）常见翻车场景

任务：写一封邮件

错误做法：
→ 创建：草稿 Agent + 语气检查 Agent + 语法检查 Agent + 格式优化 Agent
→ 4 个子任务，3 次协调，2 轮合并
→ 最后生成的邮件和普通 Agent 写的没区别问题在哪：过度设计，为不存在的复杂度买单。正确做法

任务：写一封邮件

✅ 正确做法：
→ 单个 Agent 完成
→ 必要时人工请求修改
→ 1 个任务，0 次协调检查清单

□ 这是最简单的编排方案吗？
□ 能减少几个子任务吗？
□ 我在为"可能有用"的场景设计吗？判断标准：如果资深工程师会说"这太复杂了"，那就简化。原则 3 迁移：Surgical Dispatching原原则：Surgical Changes（手术式修改）迁移后：Surgical Dispatching（手术式分发）核心原则只修改必须修改的。只清理自己制造的混乱。映射到 Harness Agent：

□ 每个子任务的职责边界明确吗？
□ 子任务会越界修改其他任务的输出吗？
□ 风格要求明确吗？（匹配现有格式/语气）子任务描述模板我用这个模板定义每个子任务：

子任务：[名称]

职责: [一句话描述做什么]
输入: [依赖哪些前置输出]
输出: [具体交付物格式]
边界: [明确不做什么]
风格: [匹配现有 XXX 的格式/语气]
成功标准: [可验证的检查点]关键：边界和不做什么，比做什么更重要。原则 4 迁移：Goal-Driven Orchestration原原则：Goal-Driven Execution（目标驱动执行）迁移后：Goal-Driven Orchestration（目标驱动编排）常见翻车场景

任务：“分析这个项目”

❌ 模糊标准：
→ 什么叫"分析"？什么叫"完成"？
→ 最后发现方向错了，但已经做了 2 小时正确做法

任务：“分析这个项目”

✅ 可验证目标：
→ 输出包含：Star 趋势、主要贡献者、技术栈、最近 10 个 Issue 分类
→ 每个维度有具体数据支撑
→ 给出"值不值得学习"的明确建议和理由多步骤任务计划模板

执行计划

1. [子任务 1] → 验证：[具体检查点]
2. [子任务 2] → 验证：[具体检查点]
3. [结果聚合] → 验证：[完整性检查]
4. [质量审查] → 验证：[验收标准]核心洞察：强成功标准让 Agent 独立循环。弱标准（“让它工作”）需要不断澄清。04 完整实战示例让我用一个完整场景展示这套方法：场景：用户请求"帮我研究小红书 AI 编程话题，写一篇分析报告" 错误做法（违反所有原则）

立即创建 5 个子任务：

1. 搜索 Agent - 搜索相关内容
2. 爬取 Agent - 抓取笔记详情
3. 分析 Agent - 数据分析
4. 写作 Agent - 生成报告
5. 审核 Agent - 质量检查

问题：

• 没有先澄清"分析报告"的具体需求

• 过度设计，可能 2 个 Agent 就够了

• 缺少明确的验收标准✅ 正确做法（融合四大原则）Step 1: Think Before Dispatching先反问澄清：• 报告用途？（内部参考？公众号文章？）• 目标读者？（小白？从业者？）• 需要多深？（概览？深度分析？）• 时间约束？Step 2: Simplest Orchestration最简方案：• 研究 Agent：负责搜索 + 数据收集 + 初步分析• 写作 Agent：负责报告撰写而非 5 个 Agent 的复杂流程。Step 3: Surgical Dispatching

  子任务 1：数据研究

• 职责: 收集小红书 AI 编程话题数据

• 输入: 关键词列表

• 输出: JSON 格式数据（笔记标题、点赞、评论、核心观点）

• 边界: 不做分析，只收集

• 数量: 30-50 条高互动笔记

子任务 2：报告撰写

• 职责: 基于数据撰写分析报告

• 输入: 研究 Agent 的 JSON 输出

• 输出: Markdown 格式报告

• 风格: 匹配公众号文章风格

• 结构: 按指定模板（背景、发现、洞察、建议）Step 4: Goal-Driven Orchestration

  验收标准

研究阶段：

• 收集至少 30 条笔记
• 每条笔记包含：标题、点赞数、核心观点
• 覆盖至少 5 个不同子话题

写作阶段：

• 报告包含 4 个章节
• 每章有数据支撑
• 总字数 3000-5000 字
• 包含可执行的洞察和建议

时间节点：

• T+30min: 研究完成

• T+60min: 初稿完成

• T+75min: 最终审核05 一份检查清单我把这套方法浓缩成了一张快速检查卡，每次用 Harness Agent 前过一遍：

  ┌─────────────────────────────────────────────────────────────┐
  │ Harness Agent - 任务分发检查卡 │
  ├─────────────────────────────────────────────────────────────┤
  │ │
  │ 🤔 Think Before Dispatching │
  │ □ 需求澄清了吗？有歧义吗？ │
  │ □ 我的假设是什么？正确吗？ │
  │ □ 真的需要多 Agent 吗？ │
  │ │
  │ 🎯 Simplicity First │
  │ □ 这是最简单的编排方案吗？ │
  │ □ 能减少几个子任务吗？ │
  │ □ 我在过度设计吗？ │
  │ │
  │ 🔪 Surgical Dispatching │
  │ □ 每个子任务边界清晰吗？ │
  │ □ 会越界修改其他输出吗？ │
  │ □ 风格要求明确吗？ │
  │ │
  │ ✅ Goal-Driven Orchestration │
  │ □ 成功标准可验证吗？ │
  │ □ 有中间检查点吗？ │
  │ □ 验收条件具体吗？ │
  │ │
  └─────────────────────────────────────────────────────────────┘建议：把这张图存下来，每次用多 Agent 系统前看一眼。06 一些延伸思考为什么这套方法有效？Karpathy 的原则之所以能迁移到 Harness Agent，底层逻辑是相通的：LLM 的缺陷不会因为你用了多 Agent 就消失，反而会被放大。单个 Agent 会过度工程化？那多个 Agent 协作只会更糟。
  单个 Agent 不问问题？那 Harness Agent 不问问题会导致整个团队跑偏。多 Agent 系统需要的是更强的元认知能力，而不是更弱。对 OpenClaw 用户的建议如果你在用 OpenClaw 搭建多 Agent 工作流：1. 在任务描述中引用这些原则• 直接告诉 Harness Agent：“遵循 Karpathy 四大原则"2. 要求展示思考过程• 复杂任务时，让 Harness Agent 先输出思考再执行3. 用检查清单评估表现• 每次任务结束后，用检查清单复盘哪里可以改进对技能开发者的建议如果你在开发 Agent 技能：1. 将原则编码到系统提示中• 不是文档，是直接的指令2. 创建标准化任务模板• 为常见场景预设最佳实践3. 添加自动检查点• 让 Agent 在关键节点自动暂停确认07 写在最后折腾 AI 编程这一年，我最大的感悟是：工具越来越强，但使用工具的心法更重要。Karpathy 的原则不是束缚，是避免常见陷阱的护栏。
  Harness Agent 的理念不是炫技，是让多个 AI 高效协作的框架。当两者结合，我们得到的不是"更复杂的系统”，而是更靠谱的结果。延伸阅读：• Karpathy 原始推文：https://x.com/karpathy/status/2015883857489522876• OpenClaw 文档：https://docs.openclaw.ai• 完整技术文档：见我的 OpenClaw 知识库关于我：太阳鸟，程序员、AI 编程实践者。2026 年专注 AI 编程赋能生活、工作、副业。已帮助100百人安装 OpenClaw，几十人用 OpenClaw 搭建生产系统。