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