工程师们曾经争论 IDE，现在争论的是 Harness。
Harness（暂且译作"脚手架"）的本质是什么？作者 Alex Ker 的定义很精准：Harness 就是 while (have next message) do {tool} 这个循环。它负责管理 LLM 本质上无状态的上下文压缩、工具调用和 I/O 处理。模型提供的是智力来源，而 Harness 让这种智力变得可用。
第一个问题：Instruction Budget
当下 Agent 最大的瓶颈是"指令预算"。前沿模型在遵循几百条指令后就会进入"痴呆区"——指令越多，越容易遗漏，幻觉越多。ETH 的研究还发现，LLM 生成的系统提示词反而降低性能，同时推理成本增加约 20%。这意味着 CLAUDE.md 和 AGENTS.md 这类全局配置，人类手写比模型生成效果更好。
核心原则：每个 Token 都应该为生存而战。描述清楚项目是什么、最终用户是谁，就够了。把行为规则塞满配置文件不是解决方案。
Progressive Disclosure：按需加载，而非一股脑塞入
直觉是"把模型可能需要的一切都提前塞进去"，但这反而消耗了宝贵的上下文空间，被迫压缩推理窗口。正确做法是 Progressive Disclosure（渐进式披露）：只在需要时让 Agent 拉取上下文，文件名本身就要自带含义。
三种界面的应用：
CLI：Agent 用 --help 发现可用子命令，再针对具体子命令运行 --help 获取参数说明。这种方式对定制化内部工具最有效——这类工具没有任何训练数据。简短一句"用 uv 做 Python 包管理，先运行 uv --help 发现子命令"就足够。
Skills：Claude Code、Codex、OpenCode 都已实现这种模式：启动时只加载 Skill 名称和描述，Agent 判断需要时才读取完整 SKILL.md。Codex 文档明确称之为"Progressive Disclosure"，是保持上下文精简的核心机制。
MCP 工具：Claude Code 在启动时加载轻量索引，按需搜索拉取完整 schema，Anthropic 报告称这减少了 85% 的上下文使用。Codex 和 OpenCode 则在启动时全部加载，文档直接警告用户限制启用的服务器数量。
R.P.I. 框架：每次 Prompt 只做一件事
HumanLayer 的 R.P.I. 框架是结构化 Prompt 的实用指南，核心是每次交互只做三件事之一：
Research：给出问题和约束，让 Agent 自主探索代码结构、历史实现和文件关联。不动手。
Plan：Agent 写出分步执行计划，人类主动验证计划的正确性。这一步偷懒，后面的代价会成倍增加。
Implement：在新的上下文中执行经过批准的计划。
本质是把最优秀工程师的做事方式结构化：拆解问题、先规划再动手、找人复审。抽象层从一行行代码变成了 Prompt，但底层的工程纪律没有改变。
Subagent 两种有效模式
用 Subagent 的判断标准很简单：主 Agent 只需要工作总结时用它。如果你需要追问"这和我之前看的东西怎么关联"，说明不该分离出去。
并行 Fan-out：适合调研场景。Alert 触发时，Agent 可以生成三个根因假设，然后并行启动三个 Subagent 各自深挖日志和指标。主 Agent 收到三个结论后综合判断，自己的上下文始终干净。
Pipeline：适合需要深度的场景。把任务依次推过不同角色——UX 设计师评估体验、架构师评估可行性、魔鬼代言人审视假设。每一步的输出成为下一步的输入，主 Agent 无需同时持有三个视角就能获得多层次的评估。
不要频繁换 Harness
当 Harness 表现不佳时，很容易产生"换一个"的冲动。作者的建议是：选一个覆盖大多数场景的，深度定制它，把每次失败当作数据点。记录什么场景下出了问题、在哪个步骤、什么条件下触发。把这些经验加入配置文件，调整 Prompt 策略。
最优秀的 Harness 是经过你的工作流反复打磨的那个——它能处理边缘情况，这些边缘情况来自团队的持续使用。