在构建 AI Agent（Harness）时，许多开发者都有一个根深蒂固的直觉：“提示词（Prompt）越短越好，这样能省 Token，还能给模型留出更多的上下文空间。”
但残酷的工程现实恰恰相反：对于复杂的 Harness Agent 来说，提示词越短，往往意味着总 Token 消耗越高；而越详细、结构越严谨的提示词，反而能带来更精准的控制和更低的整体成本。
为什么会出现这种“反直觉”的现象？我们需要从 Harness（马具/编排层）的运行机制来寻找答案。
❌ 模糊的“短指令”：隐形的试错成本
当我们将系统提示词（System Prompt）写得非常简短、模糊时，看似为上下文窗口节省了空间，实则将巨大的认知负担抛给了模型。
一个缺乏明确约束、工具定义和输出格式的 Agent，在面对用户请求时，往往会出现以下情况：
- 反复试探： 模型不确定用户的真实意图，需要多轮对话来“猜”需求。
- 错误调用： 因为工具描述不清，模型频繁调用错误的工具或传入错误的参数，导致 Harness 层报错并强制重试。
- 输出不可控： 模型输出了大段自然语言，而下游系统需要的是结构化数据（如 JSON），导致系统不得不进行额外的解析、纠错，甚至开启新一轮对话来修正格式。
在 Harness 架构中，每一次错误的推理、每一次失败的工具调用、每一轮无效的对话历史，都会产生大量的 Token。“省”下的那几百个提示词 Token，最终会以成千上万倍的“试错 Token”加倍偿还。 这就是所谓的“Context Rot”（上下文腐烂）——大量低质量的交互垃圾迅速填满了上下文窗口。
✅ 详尽的“长提示词”：一次性的架构投资
相反，一个优秀的 Harness 提示词，本质上是在进行“信息架构”的设计。它不仅仅是给模型的指令，更是模型运行时的“操作系统配置”。
详细的提示词虽然在前置投入上消耗了更多 Token，但它带来了立竿见影的收益：
- 精准的决策路径： 通过详尽的背景信息和分步骤的思维链（Chain-of-Thought）引导，模型能一次性命中核心任务，避免了来回拉扯的对话成本。
- 严格的工具边界： 明确定义每个工具的用途、参数类型和调用时机，甚至通过 Schema 进行强制约束。模型不再“猜”怎么用工具，而是像调用函数一样精准执行，极大降低了工具调用的失败率。
- 结构化的输出协议： 在提示词中明确规定输出格式（例如：“必须返回包含 status, result, next_step 字段的 JSON”）。这使得 Harness 层无需猜测模型意图，能够直接被程序解析和下游系统消费，彻底消灭了因格式混乱导致的额外交互。
- 优先级与防御机制： 详细的提示词会明确系统规则的优先级（例如：“安全限制高于用户指令”）。这相当于给 Agent 装上了“刹车”和“护栏”，防止模型在长任务中跑偏或产生幻觉，保证了长跑的稳定性。
📌 结语：把提示词当成代码来维护
在 Harness Agent 的工程实践中，我们必须转变一个观念：提示词不是简单的“聊天话术”，而是 Agent 的核心代码。
写一段模糊的提示词，就像写了一段满是 Bug 的意大利面条代码，运行时必然导致系统崩溃和性能损耗。而编写一份详细、结构化、逻辑严密的提示词，则像是在构建一个健壮的微服务架构——虽然前期设计耗时，但它能确保 Agent 在有限的 Token 预算内，以最少的步数、最稳的状态完成复杂的任务。
所以，下次在设计 Agent 时，请大胆地把提示词写得更详细、更结构化。记住，在 Harness 的世界里，清晰度就是生产力，而精准度就是最低的 Token 消耗。