iSparto 诞生记：Harness Engineering 是 Agent 时代公司治理，不止技术，更是管理
这篇文章是一名独立开发者的 Harness Engineering 实践记录。作者使用 Claude Code，设计出一套不同角色的 Agent Team，并通过这套 Team 真正完成了 iOS App "勇芽" 的开发与上线。我认为，文中最值得借鉴的是一种组织设计思路：围绕最终目标，为不同任务设置独立角色，再把这些角色组装成一个多职能团队。
我一直有一个观点：现阶段在应用 Agent 时手搓出来的工具、框架和方法，未来大概率会被大模型厂商（OpenAI、Anthropic）集成到 Agent 内部。本文作者实践的多分工团队模式，也许以后会直接内置在 Codex 或 Claude Code 里。但即便如此，这个问题暴露出来的大模型局限，以及围绕这些局限探索出的工程方案，仍然很有启发。
先说大模型的局限。问题的根源在于 Agent 自身的注意力窗口。即使一些模型已经声明支持 1M token 上下文，窗口仍然不是无限的，必然存在边界。随着信息持续输入，注意力涣散、上下文腐烂不可避免，Agent 的回答质量也会随之下降。归根到底，Harness 系统要解决的是一件事：让 Agent 知道它该知道的事，也让它不知道它不该知道的事。
这种思想有点像软件工程里的高内聚、低耦合。每个模块专注于自己的职责，一个职责尽量交给一个模块处理，不同模块之间通过协议交互，不需要了解对方的实现细节。Agent Team 也是如此：精确控制每个 Agent 的角色、职责、输入和输出，在必要时重置上下文，同时设计知识的归档与传承方案。相比于碳基人类，硅基 Agent 的优势在于不知疲倦、没有情绪、带宽很高，也能相对容易地进行状态重置和恢复。
当然，这套系统并非无懈可击。如果 AI 对某些私域知识了解不足，那么即使设计再多 Agent，也只是把同一个信息盲区拆成了更多环节。人类组织处理这类问题，通常依赖分级评审和审批链条：决策越重要，介入的角色越多，底层信息盲区也越有机会被上层角色纠偏。Agent Team 也需要类似的治理机制，否则角色分工只会提高形式复杂度，并不必然提高决策质量。
最后借用文中的一句话总结：Harness 不是纯工程问题，而是工程、管理学、组织设计和公司治理交织在一起的复合问题。
将 Claude Code 的输出 token 减少 75%。为什么没人告诉我？
Caveman 是什么
Caveman（github.com/juliusbruss... 是一个用来降低 Agent 啰嗦程度、节约 token 用量的工具，支持 Claude Code、Codex、Gemini、Cursor 等环境。它的目标不是"让模型更聪明"，而是"让模型少废话"。
Caveman 的作用机理
它本质上利用 Agent 的注入机制，在会话启动或每次提问时自动补充一段提示词，要求 Agent 以简明扼要的方式回答。
以 Claude Code 为例，Caveman 主要在以下环节注入规则：
- 每次 session 启动时，
caveman-activate.js解析默认模式，写入$CLAUDE_CONFIG_DIR/.caveman-active，再把压缩规则作为隐藏的SessionStart上下文输出给 Claude Code。参考：caveman-activate.js - 同时，
UserPromptSubmit会在每轮补一条短提醒，避免模型聊着聊着又漂回 verbose 模式。这个机制比单次 prompt 更稳定。参考：plugin.json
对于 Codex，它会修改 .codex/config.toml 文件，在 startup/resume 时 echo 一段 Caveman 规则，让会话从一开始就带上"少说话"指令。配置大意如下：
text
[features]
hooks = true
{
"hooks": {
"SessionStart": [
{
"matcher": "startup|resume",
"hooks": [
{
"type": "command",
"command": "echo 'CAVEMAN MODE ACTIVE...'"
}
]
}
]
}
}它提供的 Slash Command，例如 /caveman full、/caveman ultra，同样是一次 prompt 注入。定义这些命令的核心文件是 commands/caveman.toml。
toml
prompt = "Switch to caveman {{args}} mode..."从 Caveman 的设计思路上，可以学到什么
相比于普通做法里只给模型一句"请简洁回答"，Caveman 更聪明的地方在于它把规则变成了可持续生效的系统机制。
-
用 Claude Code hook 做自动注入。
SessionStart注入完整规则，UserPromptSubmit每轮补一条短提醒，避免模型漂回 verbose 模式。参考：plugin.json -
用 flag 文件维护状态。
.caveman-active作为当前模式状态，statusline、hook、stats 都读取它。状态外置后，模式切换、显示和统计都能解耦。参考：caveman-mode-tracker.js -
规则有边界，不是盲目压缩。
SKILL.md明确要求保留代码、命令、API、错误原文；遇到安全警告、不可逆操作、多步骤容易误读时退出压缩表达。这点很关键，否则"省 token"会牺牲正确性。参考：SKILL.md -
把效果做成反馈闭环。
/caveman-stats会读取 Claude Code transcript，统计真实输出 token，再估算节省量。即使估算不等于真实总成本，它也能让用户感知工具是否真的有用。
Caveman 的局限性
这个工具也有局限。它声称的 65% token 节省率需要谨慎看待，因为它主要省的是输出 token，而真实 Agent 成本通常还包括输入上下文、工具输出、缓存读取、推理 token 和多轮试错。短回答也可能丢失推理链、验收口径和风险解释。尤其在需求分析、架构评审、安全确认、复杂排障里，过度压缩会降低可审计性。
停止编码的那天，就是失去架构判断力的开始：一位 30 年架构师的 AI 生存指南
Q1：在 AI 越来越强大的当下，"古法编程"还有意义么？
Dennis 认为，即使是架构负责人，也仍然需要一线动手实践的经验。讽刺的是，很多一线工程师已经放弃了对代码的敬畏：他们把问题抛给 AI，等 AI 生成代码后编译运行，简单点检一下没有问题，就直接提交到代码仓库。我并不是反对 AI 编程，但这种不负责任的做法，只会制造越来越多难以维护的庞然大物。AI 写代码，AI 埋 bug，AI 解 bug，如此循环，越陷越深。
"古法编程"当然还有意义，但它的意义发生了转移。工程师不一定再逐行敲出所有代码，而是站在更高的视角上，评价 AI 生成代码的合理性，控制系统边界，并做出关键设计决策。换句话说，今天的工程师应当具备昨日架构师的知识与能力。
Q2：软件工程的核心是什么？
Patrick 认为，软件工程的核心，无论过去还是未来，都是在已有系统与不断增长的复杂性之间维持平衡。如果对过去的决策缺乏理解，却仍机械遵循，就会持续累积复杂性；时间会放大这一问题，甚至决定系统成败。
很遗憾，一些管理者并没有认识到这一点。在他们看来，既然 AI 能写出 10 个人的代码行数，为什么不把团队里另外 9 个人换成 AI？这种想法的危险之处在于，原本是 10 个人写代码，并对自己所写或所生成的代码进行判断和担责；现在，判断和担责都压到了仅剩的一个人身上。AI 可以编码，但 AI 无法承担责任。
同时，即使强如 ChatGPT-5.5（我已经有一段时间没有使用 Claude），写出的代码也不一定完全合理。这些不够合理的代码会导致项目熵增，我们只能寄希望于 AI 能力进化的速度，大过系统腐化的速度。值得庆幸的是，很多功能从设计之初就是产品经理的一厢情愿，它们很快会被替代、被遗忘，上线后也未必需要长期维护。
在这种前提下，只要 AI 生成的代码功能正确、测试通过，就可以接受，又何必过度优化。
Q3：我们能从 AI 身上学到什么？
我感触最深的是，在与 AI 的交流里，人类最欠缺的不是硬知识，反而是情绪稳定性。AI 不会产生负面情绪，但人会。公司制度不合理、项目推进受阻、交流对象难缠，都可能让人感到生气、不耐烦，产生防御心理，甚至爆发争论。很多沟通成本并不是来自技术问题，而是来自情绪和立场摩擦。
在人机协作中，这些因素基本不存在，所以它有时反而比人与人协作更高效。但反过来想，如果任由 AI "惯着"自己，会不会让人逐渐丧失与他人正常沟通和交流的能力？
也许 AI 真正教会人类的，并不只是如何解决技术难题，还有如何把自己训练成一台没有情绪波动的高效机器。即使对面的人极其难沟通，自己也能保持滴水不漏的礼貌回应，不露纰漏，也不上头。