本文对比了个人简单AI Agent与Claude Code的源码差异，指出核心差距不在模型本身，而在于Harness Engineering。文章详细介绍了8个工程模式，包括分层降级防御、分层知识注入、认知熵管理等，帮助开发者构建更可靠、安全的AI Agent。建议优先实现能力边界定义、分层降级防御等基础模式，并提供了三件可立即实施的建议。强调Harness Engineering不仅约束AI，也保留人类判断力边界。

我第一次写 AI Agent，大概用了四十分钟。

一个 while 循环，几行工具调用，模型根据结果继续推理。跑起来了，还挺好用。当时心里隐隐有一种感觉：这东西也就这样，复杂度没那么高。

然后我去看了 Claude Code 的源码结构。

目录里一千九百多个文件，四十一个顶层模块。我在那盯着屏幕看了很久。

同样是 AI Agent，同样是"让模型调工具、根据结果继续跑"，差距在哪？

这篇文章想回答这个问题。结论先放这里：差距不在模型，在Harness Engineering。

---

一、能跑，和可靠地跑，是两件完全不同的事

先说一个事实：AI Agent 的核心逻辑，真的不复杂。

while stop_reason == "tool_use":
    result = execute_tool(tool_call)
    response = call_model(result)

就这样。任何会写代码的人，两小时之内都能写出一个"能跑"的 Agent。

但"能跑"和"可靠地跑"之间，隔着一个巨大的工程鸿沟。

"能跑"意味着：在你盯着屏幕测试的那几轮对话里，它没出问题。

"可靠地跑"意味着：它在你不盯着的时候，跑了两百轮，没有开始胡说八道；跑了一个星期，记忆没有混乱；被用户用各种奇怪的方式提问，没有执行危险操作；调用了十万次，账单没有超出预算。

这两者之间的距离，就是那些工程代码在填的坑。

2026 年 4 月，VILA Lab 发表了一篇专门分析 Claude Code 架构的学术论文，研究者系统阅读了它的公开 TypeScript 源码，最后得出的结论是：Claude Code 的核心，永远是那个 while 循环。数以万计的工程代码，做的事情只有一件——让这个简单的循环能安全、持久、经济地跑下去。

这和我自己读代码的感受是一致的。

---

二、四个维度，八个模式

在我看来，这些工程代码解决的问题可以归为四类：

• Harness Engineering工作台：上下文窗口是有限的，如何让 Agent 在有限的空间里保持清醒？
• Harness Engineering记忆：知识要存，但不能全塞进上下文，还不能随着时间越来越乱。
• Harness Engineering行为：Agent 能执行真实命令之后，如何确保它不做危险的事？
• Harness Engineering成本：按 token 计费的世界里，如何不让 Agent 把钱烧完？

从这四个问题出发，可以提炼出 8 个设计模式。它们不是 Claude Code 的专利，而是任何 Agent 系统都绕不开的工程智慧。

---

模式一：分层降级防御

问题：Agent 需要大量背景知识，但上下文窗口装不下。

全部塞进去：token 暴涨，当前任务内容被挤走，推理质量下降。不放：Agent 又会无知地做决策。两难。

解法：把知识分三层，分别对待。

• 永久索引层：每次启动都加载，内容要短、稳定、高价值。大约一千 token 以内。
• 按需注入层：只在相关的时候加载，比如某个 API 文档、某个模块说明。
• 历史归档层：不默认加载，只提供搜索能力。需要的时候检索，不需要的时候不占空间。

Claude Code 的做法是：MEMORY.md 作为轻量索引每次启动加载，CLAUDE.md 和各种 Topic Files 在相关时注入，历史 Transcript 只可搜索不占常驻上下文。

2026 年初，Anthropic 还正式推出了 Auto-Memory 功能：Claude Code 在工作过程中会自动维护 MEMORY.md，跨会话的上下文交接不再需要人工操作。

你能怎么做：把项目技术栈、核心规则、关键Harness Engineering常驻系统提示词；把 API 文档做成可调用工具；把历史对话从上下文里移出来，改成搜索接口。

---

模式二：分层知识注入

问题：很多团队一上 Agent 知识管理，第一反应是"上向量数据库"。

这个直觉没有错，但顺序错了。

解法：先分层，再谈检索技术。

在选择任何技术方案之前，先回答这一个问题：

这条知识，应该常驻、按需注入、还是只允许被搜索？

这三个答案对应的架构决策完全不同。常驻知识浪费 token；按需注入的东西当成常驻，占了有效空间；可检索的东西强行放进上下文，搞乱了推理。

有一个细节值得注意：Claude Code 的自动压缩机制，在压缩历史对话时，优先保留"接下来要做什么"，而不是"过去为什么这么做"。这意味着：关键规则必须放在 CLAUDE.md，而不是依赖对话历史。 对话里说过的Harness Engineering，可能在压缩后消失。

---

模式三：认知熵管理

问题：Agent 长期运行，记忆会越来越乱。

过时的信息没有删，相互矛盾的结论同时存在，重复的经验不断堆积。这就是"记忆熵增"。熵增到一定程度，Agent 会开始依据错误的信息做决策，而且你很难察觉。

解法：定期对记忆做整理。

整理要做四件事：审查现有条目、删除过时信息、合并重复内容、解决互相矛盾的结论。

Claude Code 里有一个 Auto Dream 机制，利用空闲时间让 LLM 自动审查记忆文件，做这四件事。

你能怎么做：最简单的方案，是设置一个定期提醒，每两周人工检查一次记忆文件。进阶方案是后台跑一个 Agent，输出"需要更新/删除/合并"的清单，然后人工确认。

这个模式看起来不紧急，但凡是打算长期运行的 Agent，都必须提前设计进去。否则几个月后，你会发现 Agent 开始犯一些奇怪的错误，而根源是它在依据半年前就过时的记忆在做判断。

---

模式四：纵深防御

问题：只靠一层安全策略，总会有绕过的方式。

只靠提示词Harness Engineering？太脆。只靠正则匹配？太窄。只靠黑名单？覆盖不全。任何单一机制都有盲区。

解法：多层独立防线，每层用不同机制，deny 优先于 allow。

Claude Code 的安全管线有四层：规则引擎（处理明确的危险操作）→ 低风险快速放行 → 白名单匹配 → LLM 安全分类器（独立模型负责处理模糊情况）。

你能怎么做：

• 第一层：硬编码危险操作拦截。删除文件、修改系统配置、访问敏感路径——快、便宜、稳定。
• 第二层：基于历史和白名单放行常用安全操作。
• 第三层：不确定的操作，弹窗确认或调独立模型分类。

这里有一个容易踩的坑：很多人以为"纵深防御"就是把同一种检查叠加多次。不是的。真正的纵深防御，要求每层使用不同的机制。 叠十层正则，和叠一层正则一样脆。

---

模式五：双 AI 对抗

问题：如何信任一个不完全可靠的 AI？

让 Agent 自己检查自己，有一个系统性的问题：它可能对某类风险有盲区，而你不知道那个盲区在哪。更麻烦的是，上下文里的内容会影响它的判断——如果有人在对话里注入了恶意内容，任务模型可能已经被影响了。

解法：用一个独立 AI 监督另一个 AI，两者上下文完全隔离。

Claude Code 里，任务模型负责干活，安全分类器是一个完全独立的模型实例，只负责审查操作安全性。分类器看不到任务模型的推理过程，也看不到任务模型上下文里的内容。 这意味着就算任务模型被 prompt injection 污染了，安全判断依然不受影响。

你能怎么做：在数据库写入、文件删除、外部 API 调用、权限变更这类关键操作之前，调用一个独立模型做审查。关键是"独立"——不要复用任务模型的上下文。

---

模式六：缓存感知架构

问题：LLM 按 token 计费，多轮对话成本线性增长。

系统提示词每次都全量发送，工具说明每次都重复，历史消息越来越长。调个几百次，账单就很好看了。

解法：把系统提示词分成稳定区和动态区。

• 稳定区：角色定义、工具说明、全局规则。内容不变，可以被 Prompt Cache 命中，重复内容只计费一次。
• 动态区：当前任务、临时上下文、用户输入。每次可能变化，放在后面。

规则很简单：不变的内容放前面，会变的内容放后面。

顺便补一个数据：研究发现，LLM 在上下文从 1K 增长到 32K 时，复杂任务的表现会下降 50-70%。这意味着控制上下文长度，不只是省钱，还是在防止 Agent 变迟钝。两件事，一个设计解决。

---

模式七：编排者模式（以及它的进化形态）

问题：复杂任务需要多个 Agent 协作，但"指挥官"如果既负责规划又亲自干活，它的上下文很快被实现细节塞满，失去全局视野。

解法：编排者只做三件事——分活、收活、做决策。具体执行交给 Worker Agent。

Claude Code 在 Coordinator Mode 下，Claude 从"全栈工程师"变成"技术经理"，通过 AgentTool 启动 Worker，设置并发上限、超时时间、消息数量硬限。

但这个模式在 2026 年 5 月有了一次重大进化。

Anthropic 在 5 月 28 日发布了 Dynamic Workflows：Claude 现在可以自动编写 JavaScript 编排脚本，把计划存储在脚本变量里而不是自己的上下文窗口中，然后由独立的运行时在后台执行，可以同时跑数十到数百个并行子 Agent，每个子 Agent 从不同角度处理问题，其他 Agent 负责验证并反驳它们的结论，持续迭代直到答案收敛。

这个架构解决了一个根本问题：计划不再占用上下文窗口。 不管任务有多大，编排者的上下文始终干净。

Bun 的创始人 Jarred Sumner 用它在 11 天内完成了约 75 万行代码的 Zig-to-Rust 迁移，测试套件通过率 99.8%。这种规模的任务，以前的预算单位是季度，现在是天。

---

模式八：能力边界即架构边界

这是最重要的一个模式，也是最容易被忽视的。

问题：在提示词里写"你不能做 X"，是不可靠的。

LLM 不是确定性系统。它可能忽略指令，可能遗忘Harness Engineering，可能被上下文干扰，可能被 prompt injection 覆盖。"请不要这么做"这句话，在足够的压力下，效力等于零。

解法：不在提示词层面Harness Engineering行为，在架构层面消除能力。

如果 Agent 不应该做某件事，就不要给它完成这件事的工具。

Claude Code 在某些阶段只有一个 bash 工具，所以它物理上不可能发邮件，不可能调用支付接口，不可能操作你不希望它碰的东西。安全分类器上下文与任务模型隔离，所以无论任务模型被如何注入，安全判断都不受影响。Worker Agent 没有规划工具，所以它不可能越权去指挥其他 Worker。

你能怎么做：

设计 Agent 之前，先列两张表：

1. Agent 应该能做什么，需要哪些工具

2. Agent 不应该做什么

然后检查第二张表里的每一项：它能通过第一张表里的工具间接实现吗？

如果可以，你就有了一个架构级的安全漏洞。修复方式不是加一句"请不要这样做"，而是移除那个工具，或者限制它的权限边界。

“不在菜单上的菜”，比"菜单上写着但不让点"，安全一百倍。

---

三、优先级速查

8 个模式，不需要一次全部实现。按照下面的顺序来：

第一天就做（P0）

• 模式 #8：能力边界即架构边界。零成本，但这是所有安全设计的底线。
• 模式 #1：分层降级防御。不做这个，Agent 跑多轮之后必然变迟钝。

上线前做（P1）

• 模式 #4：纵深防御。只要 Agent 能执行真实命令，就必须有。
• 模式 #2：分层知识注入。知识量超过上下文窗口一定比例后，必须分层。
• 模式 #6：缓存感知架构。调用量上来之后，成本差异会非常明显。

复杂场景引入（P2）

• 模式 #5：双 AI 对抗。涉及敏感操作时强烈建议。
• 模式 #7：编排者模式。单 Agent 搞不定的时候再引入。

长期运行后补齐（P3）

• 模式 #3：认知熵管理。短期项目可以等，但要记得补上。

---

四、三件今天就能做的事

第一件：审计你的工具集

列出 Agent 现有的所有工具，再列出它不应该做的所有事情。检查两张表有没有交集。

有交集，说明存在架构级漏洞，修复方式是移除或限制工具能力，而不是加提示词。

第二件：给上下文加一层压缩

哪怕只是最简单的版本：超过 5 轮对话后，把 3 轮以前的工具输出替换成一句话摘要。这一步做完，Agent 的长对话表现会有明显提升。

第三件：拆分系统提示词

把不变的内容（角色定义、工具说明、全局规则）放前面，把每次会变的内容（当前任务、用户输入）放后面。如果你用的 API 支持 Prompt Cache，这一步立刻省钱。

---

五、最后说一句

2026 年 4 月那篇分析 Claude Code 架构的学术论文，最后提了一个让我印象深刻的观察：

Anthropic 自己对 132 名工程师和研究员做了一项研究，发现过度依赖 AI 辅助编程的开发者，在代码理解测试中得分低了 17%——他们把理解的能力"外包"给了 AI，而自己的能力在悄悄退化。

这不是 Agent 架构的问题，但它提醒了我们：Harness Engineering不只是用来约束 AI 的，也是用来保留我们自己判断力的边界。

知道在哪里放权，在哪里保留控制，这本身就是一种需要刻意设计的能力。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？