从 Prompt 到 Harness：Claude Code 源码泄露背后，Agent 工程正在重写软件工程范式

在大模型能力快速跃迁的当下，行业叙事正从“模型有多强”转向“系统如何驾驭模型”。近期围绕 Claude Code 的源码分析，意外揭开了一个更关键的趋势：AI 编程助手的竞争，已经从 Prompt Engineering 走向更复杂的系统工程——Harness Engineering。

这不仅是一个工具层的升级，更像是一场软件工程范式的重构。

导语：一个被低估的转变

过去两年，开发者社区的共识是：AI 可以写代码。

但当 Agent 真正进入生产系统，一个更本质的问题浮现出来——AI 的问题不在能力，而在可控性。

Claude Code 的工程化设计恰好回应了这一点：它并不是“LLM + Prompt + Tools”的简单拼装，而是一个围绕模型构建的完整操作系统。这种设计思路，也揭示了当前 AI 工程演进的方向：

• Prompt Engineering 解决“如何表达需求”
• Context Engineering 解决“如何提供足够信息”
• Agent Engineering 解决“如何执行复杂任务”
• Harness Engineering 解决“如何让系统长期稳定运行”

问题开始从“生成代码”转向“控制系统行为”。

Claude Code：从工具到 Agent System

从源码结构来看，Claude Code 更接近一个“Agent 操作系统”，而非传统意义上的开发工具。其核心设计可以概括为几个关键层：

1. 动态 Prompt 编排：上下文即运行时环境

Claude Code 并不依赖静态 Prompt，而是通过运行时动态拼装上下文，包括：

• 当前工作区状态（如 git status）
• 项目规范文件（如 CLAUDE.md）
• 历史记忆（Memory）
• MCP 协议接入的外部工具状态

本质上，Prompt 被“工程化”为一种系统级配置，而非文本技巧。

这也是 Context Engineering 的进阶形态——上下文不再是输入，而是环境。

2. 多 Agent 分工：强制角色隔离

系统内部通过多种模式（如 plan / auto / manual）以及子 Agent 机制，实现职责拆分：

• 规划 Agent：只读，负责分析与拆解任务
• 执行 Agent：负责具体代码生成与操作
• 验证 Agent：专门用于发现问题

这种“读写分离 + 执行与评估分离”的设计，本质上是在解决一个核心问题：
避免模型在“边想边做”过程中产生幻觉和逻辑混乱。

3. 验证优先：从生成导向到验证导向

Claude Code 的一个关键理念是：生成不等于完成。

系统内置大量验证机制：

• Build / Test / Lint / 类型检查
• 数据库迁移校验
• 边界条件测试
• 类似 /doctor 的诊断工具

甚至引入“破坏性验证”思路，让 Agent 主动尝试“搞坏系统”。

这标志着 AI 编程从“生成代码”走向“保证正确性”。

4. 工具治理：基于悲观假设的执行体系

在工具调用层，Claude Code 并不假设模型是可靠的，而是默认“会出错”：

• 执行前：参数校验、路径验证、防目录穿越
• 执行中：Hook 机制插入控制逻辑
• 执行后：失败兜底与上下文补充

这种设计体现了一种工程哲学：AI 系统必须在错误中运行，而不是避免错误。

5. 生命周期管理：让 Agent 能“长期运行”

区别于 Demo 级工具，Claude Code 具备完整的生命周期管理能力：

• 会话中断与恢复（如 /resume）
• 自动上下文压缩（防止 Token 爆炸）
• 后台任务与异步 Agent 管理

这类能力并不“炫技”，但正是其迈向企业级系统的关键。

从 Loop 到控制系统：Harness Engineering 的核心

很多团队在实践 Agent 时，会引入 Loop 机制：

任务 → Agent → 输出 → 再输入 → Agent

这看似是“闭环”，但实际上只是让系统持续运行，并没有解决失控问题。

典型问题包括：

• 偏差累积：每一轮生成都可能引入误差
• 架构漂移：系统结构逐渐失去一致性
• 局部最优：只修复当前问题，破坏全局

Claude Code 的启发在于：Loop ≠ 可控系统。

Harness Engineering：把 AI 系统变成“可控闭环”

所谓 Harness Engineering，可以理解为：

为 Agent 构建一个具备约束、反馈和上下文的执行环境，使其行为可预测、可修正、可持续运行。

其核心由三部分构成：

上下文（Context）

减少错误的产生，而不是事后修复：

• 明确接口与边界
• 提供结构化信息
• 降低模型猜测空间

约束（Constraints）

限制系统的“可行动空间”：

• 权限控制（如文件访问范围）
• 架构规则（分层、依赖限制）
• 工具使用边界

反馈（Feedback）

实现自动纠偏：

• 测试失败 → 强制修复
• CI 不通过 → 阻止合并
• 监控与日志 → 持续观测

三者共同构成一个典型的控制系统。

软件工程的范式转移：从“构建”到“控制”

如果用更宏观的视角来看，这一变化类似于控制论的回归。

传统软件工程：

• 人写代码 → 系统运行
• 系统是静态产物

AI 时代的软件工程：

• 人描述目标 → Agent 持续生成 → 系统不断演化
• 系统是动态过程

这带来一个关键变化：

工程对象，从“代码”，变成了“行为系统”。

因此，工程关注点也发生转移：

• 从“代码是否正确” → “系统是否稳定”
• 从“功能是否实现” → “行为是否收敛”
• 从“写代码” → “设计控制机制”

行业启示：Agent 竞争进入“系统工程时代”

Claude Code 的架构给行业释放了一个明确信号：

Agent 的竞争，正在从模型能力转向系统能力。

关键能力包括：

• 上下文管理（Context as System）
• 权限与安全（Fine-grained Control）
• 多 Agent 协作（Role Separation）
• 自动验证（Verification-first）
• 生命周期管理（Long-running System）

换句话说，决定一个 AI 工具上限的不再只是模型，而是围绕模型构建的工程体系。

结语：真正的问题，不是 AI 能不能写代码

随着大模型不断进化，“AI 会不会取代程序员”已经不再是最重要的问题。

更关键的是：

当系统开始持续生成代码，我们如何保证它不会走向失控？

Harness Engineering 给出的答案不是更强的模型，而是更严密的系统设计。

这或许意味着一个新的工程时代已经到来——
软件工程，不再只是构建系统，而是设计一个能够自我修正的控制系统。