你有没有问过自己：如果 Claude 这样的大模型真的能自动跑测试、改代码、改数据库，那它是什么时候变成"危险品"的？
不是在它学会写代码的那一刻。而是在它被放进了真实的代码库、真实的 shell、真实的团队工作流以后。
这就是这篇文章想聊的核心问题——Prompt 决定它怎么说话，Harness 决定它怎么做事。
聪慧的模型 vs 靠谱的系统
很多人还在用"模型聪不聪明"这个维度来评价 AI Agent。但我觉得这个角度就错了。
一个只输出文本的聊天机器人，出错了就是增加沟通成本——你需要再问一遍，或者去别的地方验证。这种失误，本质上是可恢复的。
但一个能运行命令、写文件、删目录、改 Git 配置、访问网络的 Agent 呢？它出错后留下的不是文字，而是执行后果——目录结构变了、进程中断了、配置损坏了。这些不是对话记录，是系统状态的改变。
换句话说：一个 Agent 出错的代价，和它的权限成正比。
所以，真正决定一个 Agent 能不能用，不是它能不能想到正确答案，而是它在行动前有没有足够的约束来防止错误答案被执行。
约束不是限制，是安全气囊
有人会反驳：这不就是"把 AI 用户圈到沙箱里"吗？这样不是浪费了模型的能力吗？
我的答案是：没有约束的能力，本质上是不可用的。
想象一个医生，他的医术无敌，能诊断任何疾病。但他没有任何规范流程——想给病人开什么药就开什么药，想要什么检查就要什么检查，甚至想改一下病人的用药记录就随便改。你会相信他吗？
不会。因为能力强的人，出错时伤害也大。所以我们给医生规范、给他工作流、给他制度约束。这不是在削弱他，反而是让他的能力可被信任。
Harness（缰绳、束具）的意思就在这。它不是 AI 的笼子，而是 AI 的工程学基础——一组持续生效的控制结构，用来约束模型在工程环境中的行为边界。
过度追求"自然体验"的代价
我看过不少 AI 产品团队，他们的目标是让 Agent 用起来"像一个聪明同事一样自然"。这个目标本身没问题，但执行路线往往有问题。
他们会说："我们要减少约束，让模型更自由地思考。" "我们要让用户体验更自然，不要有那么多确认框。"
结果是什么？系统获得了类似人的失误模式——凭一时冲动乱删文件、凭口误改错变量、凭理解偏差搞坏配置。但它没有获得人的"承担后果的能力"——人会为自己的错误负责，但一个失控的 Agent 只会在日志里留下一行 ERROR。
这是个巨大的陷阱。过度追求"像人一样自然"的代理体验，常见的结果就是：系统具备了人的失误模式，却没有承担后果的能力。
这本书讲的不是"Claude 怎么写代码"
我要坦白：这不是一份"Claude Code 源码注释汇编"。我没有把 Claude Code 的代码逐行翻译成中文，然后说"你看，它就是这样工作的"。
反而，我是从源码的架构结构里，反推出了一些工程原则。换句话说，我问的是：
为什么 Claude Code 要这样设计？
为什么错误路径要按照主路径来设计？
为什么验证必须进入完成定义？
为什么权限是系统的器官，不是装饰品？
为什么上下文是资源，不是免费午餐？
这些问题的答案，才是真正值得学的东西。因为这些原则对任何 Agent 系统都适用——不管你用什么模型、不管你的团队规模多大。
核心原则预告
如果你要快速了解这个系列的核心思想，我可以提前剧透：
错误路径要按主路径设计 —— 每一种可能失败的情况，都不是"另外处理"，而是主流程的一部分
验证必须进入完成定义 —— 不验证的"完成"，就是偷工减料
权限是系统器官 —— 权限检查不是可选的框架代码，而是系统的神经系统
上下文是资源 —— 消耗上下文就像消耗 CPU，要精打细算
多代理要角色分离 —— 不同的 Agent 不能没有边界，否则大家都在踩对方的脚
团队制度比个人技巧重要 —— 靠天才出错率低，靠制度才能做出靠谱的系统
这个系列是给谁的
- 如果你是 AI 产品经理，想理解 Agent 系统为什么这样设计
- 如果你是工程师，想搞清楚怎样约束一个有权限的 AI 系统
- 如果你是架构师，想看看有没有跳出"聊天机器人"思路的可能
- 如果你就是想跟上时代，不想只停留在"Claude 很聪明"的认知水位
那这个系列可能对你有点用处。
最后的话
有个很有意思的观察：在人工智能的早期，我们害怕的是"机器太笨"。现在害怕的是"机器太聪明，我们控制不了"。
这种转变本身说明，真正的瓶颈已经从能力转向了可靠性。一个能力强但不可靠的系统，比能力弱但靠谱的系统危险得多。
而可靠性不是买来的，也不是用 Prompt 工程就能要来的。它是架构出来的。
这就是为什么，我想花时间讲讲 Harness。
<!-- 改动说明：开篇用"聪明模型 vs 靠谱系统"的对比来吸引注意力，中间用医生的比喻解释约束的价值，最后预告核心原则。全文口语化，避免学术术语，强调实战意义。 -->