https://guangmingluo.github.io/tags/%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/Recent content in 架构设计 on Guangming BlogHugozh-cnFri, 08 May 2026 14:00:00 +0800https://guangmingluo.github.io/post/harness-engineering-deep-dive/Fri, 08 May 2026 14:00:00 +0800https://guangmingluo.github.io/post/harness-engineering-deep-dive/一个反直觉的发现 如果你有机会翻开一个生产级 AI 编码 Agent 的源码，你最先期待看到什么？模型调用的逻辑？工具执行的编排？权限控制的判断？ 你可能不会期待看到这个：在 Claude Code 中，控制模型行为的主要手段不是代码逻辑，而是提示词。 这不是比喻。当我们说"控制面"的时候，在传统软件中，它意味着 if-else 分支、策略模式、配置中心——总之，是代码。但在 Claude Code 的世界里，系统提示词的每一段落都在引导模型该做什么、不该做什么、优先做什么、什么条件下放弃。工具描述不是静态字符串，而是根据权限模式动态生成的函数。89 个 Feature Flag 中的大部分不是控制代码路径，而是控制注入到提示词中的内容。 这就像你发现一辆汽车的转向系统不是机械连杆，而是驾驶员的语音指令——而且它真的管用。 《驾驭工程》这本书，把从 Claude Code v2.1.88 源码中逆向分析出的这些发现，提炼成了一个更深的命题：当 AI 成为系统的执行者，“控制"这件事本身需要被重新定义。 这不是一个 Prompt Engineering 的问题，而是一个全新的工程学科的问题。 驾驭工程 ≠ Prompt Engineering 先说清楚一件事：驾驭工程不是 Prompt Engineering 的升级版。 Prompt Engineering 解决的核心问题是：如何让模型在一次交互中给出更好的回答。它的基本单位是"一条提示词”，它的优化目标是"这一次的输出质量"。 驾驭工程解决的核心问题是：如何设计一个系统，让 AI 在长时间、多轮次、有状态的执行过程中，始终表现出可预测、可控、可靠的行为。它的基本单位是"一个系统"，它的优化目标是"整个运行周期的行为一致性"。 这个区别是本质性的。打个比方：Prompt Engineering 是教你如何跟一个聪明的临时工说清楚一次任务的要求；驾驭工程是设计一套组织架构、流程规范和文化系统，让一千个聪明的临时工在没有任何直接监督的情况下，持续做出一致的决策。 从 Claude Code 的源码中，我们可以清楚地看到这种系统性思维的具体形态： Agent Loop 不是一个简单的 while 循环，而是一个包含了权限拦截、并发编排、流式中断和压缩触发的状态机 系统提示词 不是一个静态文本块，而是一个由多个段落按条件拼接的动态文档——模型身份、工具描述、上下文压缩结果、用户覆盖层，每一层都在运行时注入 工具注册 有四种策略：无条件注册、构建时 Flag 守卫、运行时环境变量守卫、运行时函数守卫——同一套工具在不同模式下呈现给模型的面貌完全不同 工具描述是函数而非字符串 ——同一个 Write 工具在 allowlist 模式下和默认模式下的描述不一样，因为模型需要知道的信息取决于它当前被授予的权限 这些不是"高级提示词技巧"，这是系统架构。