生产力的发展不管人的死活，但人可以管自己的死活

上个月我跟一个做外贸的朋友吃饭，他说公司刚裁掉了整个客服团队，换成了 Agent。十二个人，一夜之间变成了一笔月费。他不是冷血，他算过账：Agent 的响应速度是人的 8 倍，客户满意度反而上升了 15%。他说这话的时候表情很复杂，因为被裁的人里有一个跟了他六年的老员工。

我当时没接话。因为我自己也在经历类似的事。我做了九年工程师，过去一年眼看着身边的岗位一个接一个被 Agent 吃掉。不是未来的事，是正在发生的事。

这篇文章想讨论的问题很直接：当技术进步快到社会来不及反应，会发生什么？

效率这辆车不会停

先说一个让人不舒服的事实：讨论效率该不该推进，没有意义。

这就像两只蚂蚁讨论被车轮压的时候怎么更舒服一点。车不会因为蚂蚁的讨论而停下来。人类社会的发展一直是效率驱动的，所有试图阻挡效率的力量，最后都被碾过去了。手工织布挡不住珍妮纺纱机，马车夫挡不住汽车，实体书店挡不住电商。

但效率的推进方式是可以选择的。

英国工业革命初期，童工遍地，工人每天干 16 个小时，肺里全是煤灰。效率确实提升了，代价是一整代人的健康和尊严。后来工会运动起来了，《工厂法》通过了，劳动保障制度建立了。这些东西没有阻碍效率，它们让效率的推进不至于把社会撕碎。

所以真正的问题从来不是"要不要效率"，而是"效率碾过来的时候，谁来接住被碾的人"。个体要拼命适应，社会要拼命兜底。 这两件事不矛盾，缺一不可。

时间差在缩短

每次技术革命都有一个时间差：技术跑在前面，制度在后面追。

蒸汽机 1760 年代开始普及，英国第一部《工厂法》1833 年才通过，中间隔了将近 70 年。电气化从 1880 年代铺开，成体系的劳动保障到 1930 年代才成型，大约 50 年。互联网 1990 年代爆发，GDPR 2018 年才落地，间隔 20 多年。

规律很明显：每一轮技术革命，制度追赶的时间在缩短。但技术加速的幅度更大。

Agent 的扩散速度比以上任何一次都快。蒸汽机需要建工厂，电气化需要铺电网，互联网需要拉光纤。Agent 需要什么？一个 API key。部署成本几乎为零，扩散速度几乎没有物理限制。

这意味着这一轮的时间差可能被极度压缩。技术用两三年完成的颠覆，制度可能需要十年才能回应。中间这段真空期，就是社会震荡最剧烈的时候。

人往哪去

过去一百年，就业市场有一个隐性的"吸纳器"机制。

制造业自动化了，工人去了服务业。收银员、餐厅服务员、快递员，这些岗位吸纳了大量从工厂出来的人。服务业开始萎缩的时候，一部分人又流向了知识工作。数据标注、内容运营、初级编程，这些新岗位又接住了一波人。

每一次技术革命消灭一批岗位，同时创造另一批岗位。这个循环运转了很久，久到很多人以为它是自然规律。

Agent 正在打破这个循环。

它吃掉的不是某一层岗位，而是跨层的。客服、数据分析、初级编程、内容撰写、法律文书、财务审计，这些分属不同行业、不同层级的工作，Agent 一口气全能做。以前你从制造业出来，至少还能去服务业。现在服务业和知识工作同时被压缩，人往哪去？

我认识一个做了八年翻译的朋友，去年底失业了。她试过转行做 AI 提示词工程师，学了三个月，发现这个岗位本身也在被 Agent 替代。她现在在考虑开一家面包店。我不确定这是降级还是转型，但我知道这种"被挤出来又找不到新容器"的感觉，正在越来越多人身上发生。

一大批人失去收入来源，这件事必须被解决。不是因为善良，是因为不解决就会掀桌子。社会矛盾积累到临界点，它会以任何你想不到的方式爆发。

UBI 和那些创可贴

解决方案已经有人在想了。

Sam Altman 提了一个思路：不对劳动征税，改对 AI 公司的算力和资本征税，建立"美国公民权益基金"，让每个公民从 AI 创造的财富中分一杯羹。 英国投资部长在公开讨论 UBI（无条件基本收入）的可行性。斯坦福 HAI 发了支持 UBI 的重量级论文。2026 年美国企业研究所做了一项元分析，涵盖 122 个 UBI 试点项目，其中 30 个随机对照实验显示净就业效应为 +0.8%，也就是说拿了基本收入的人并没有躺平，反而略微更积极地参与了劳动市场。

这些数据让人稍微安心了一点。但我越想越觉得，UBI 解决的只是"钱从哪来"的问题。更大的问题依然存在。

过去两百年，整个社会运转的底层逻辑是一条链：你出卖劳动，获得收入，参与消费，推动经济循环。你的社会身份、你的人生意义、你和社会的连接方式，全部挂在"劳动"这个钩子上。你是工程师、是医生、是教师、是司机，这些标签定义了你是谁。

当劳动不再被需要，这个钩子就断了。

你每个月收到一笔 UBI，够吃够住。然后呢？你是谁？你的一天怎么过？你跟这个社会的关系是什么？这些问题听起来很哲学，但它们会以非常具体的方式爆发出来：抑郁、成瘾、社区瓦解、极端思想蔓延。不是猜测，是每一个长期高失业率地区都在发生的事。

生产关系永远在追赶

马克思说过一句被引用了无数次的话：生产力决定生产关系。翻译成大白话就是：你用什么方式生产，决定了社会怎么组织。

Agent 时代的生产力结构跟以往完全不同。以前的机器替代体力，人还有脑力。现在 Agent 替代脑力，人剩下的只有意图和判断。生产力越高，需要的人类劳动越少，但劳动是绝大多数人获取收入的唯一方式。这个矛盾不解决，社会撕裂只会加剧。

各个社会正在摸索不同的路径。美国倾向于放任市场，用低福利维持一个庞大的底层人口，不优雅但便宜。欧洲走高福利高税收的路线，已经有国家在讨论对 Agent 使用征税。东亚更习惯国家主导产业转型，效率最高但容错最低，一旦方向判断错了代价巨大。

没有哪条路被验证过。我们都在做实验。

我个人觉得最终的方向可能是某种混合体：UBI 提供基本保障，同时把 Agent 的使用权民主化，让每个人都能调用 AI 的生产力去创造价值，而不是只有大公司才玩得起。就像互联网早期只有大机构才能上网，后来变成人人都有智能手机一样。

教育是最先该动的齿轮

在所有需要重写的社会契约里，教育可能是最紧迫的一个。

现在的教育体系还在教人"掌握知识和技能"。但 Agent 最擅长的就是知识和技能。你花四年学会的东西，Agent 在训练阶段就已经掌握了，而且比你更精确、更全面、不会遗忘。

教育的重心需要从"教答案"转向"教提问"。从教你怎么解一道题，变成教你怎么发现这道题值不值得解。从教你用什么工具，变成教你怎么判断工具给出的结果对不对。

我自己带过几个实习生，最近一个让我印象很深。他的代码能力一般，但他特别擅长一件事：把一个模糊的商业需求拆解成 Agent 能执行的任务序列。这个能力在两年前根本不存在这个品类，现在它可能是最值钱的技能之一。

没有人教过他这个。他是自己在实践中摸出来的。这说明教育体系还没有跟上，但也说明人有自我适应的能力。

浪来了，搭船还是等船

写到这里我想诚实地说：我不知道社会契约最终会被重写成什么样子。UBI 会不会普及？Agent 使用权会不会民主化？教育体系会不会转型成功？这些问题我给不了答案。

但有一件事我比较确定：等着制度来救你，大概率来不及。

制度的调整需要共识，共识需要时间，时间是 Agent 时代最稀缺的东西。蒸汽机时代你有 70 年的缓冲期慢慢调整，这一轮你可能只有 5 到 10 年。

作为个体，能做的事情很具体：保持对 Agent 的手感，不断练习"定义问题"而非"解决问题"的能力，同时关注社会制度层面的变化，在有机会发声的时候发声。

作为社会，需要做的事情也很具体：加速 UBI 的试点和验证，推动 AI 使用权的普惠化，重新设计教育体系的评估标准。这些事情每晚一年，被甩在后面的人就多一批。

生产力的发展确实不管人的死活。但人可以管自己的死活。前提是你动得够快，同时推着制度也动起来。

看完了？说点什么呢

同一个 AI 模型，换个壳，表现天差地别——壳就是 Harness

从一个事故说起

前两篇分别讲了 AI 怎么"看"（Prompt 和 Context）和怎么"做"（MCP 和 Skill）。到这里，拼图看起来快完整了：你把信息喂给 AI，AI 想好了，通过工具去执行，执行还有标准流程可以遵循。

但我最近碰到的一件事，让我意识到中间缺了一块关键拼图。

我用 AI 帮一个项目做重构——把一批旧的 API 接口迁移到新的路由结构。我给了它清楚的 Context，配好了 Skill，MCP 也接上了代码仓库。它开始干活了。前几步都很顺利：识别旧路由、创建新文件、迁移逻辑。

然后它自己做了一个判断：它认为有些旧的测试文件"已经不需要了"，直接删掉了六个测试用例。

从 AI 的角度看，这个判断不是没有道理——那些测试确实是针对旧路由写的。但它不知道的是，其中三个测试覆盖了一些边界条件的回归检测。删掉之后，我们的持续集成就裸奔了。

问题出在哪？

不在 Prompt——我的指令很清楚。不在 Context——它看到了所有相关文件。不在 MCP——工具调用本身没问题。不在 Skill——操作流程是对的。

问题在于：谁来决定 AI 可以删文件？谁来设定"做到这一步要停下来问我"？谁来管理这整个循环的节奏和边界？

什么是 Agent

在讲解决方案之前，先定义一个贯穿本篇的核心概念。

Agent 是什么？

一句话： 一个能感知环境、自主决策、采取行动的 AI 系统。

跟传统程序的区别： 传统程序是线性的——你写好代码，它按顺序执行，遇到分支按条件走，不会自作主张。Agent 不一样。你给它一个目标（"重构这批 API"），它会自己拆解任务、规划步骤、在执行过程中根据结果调整策略。它有"主动性"。

组成： 一个 Agent = Prompt + Context + MCP + Skill + Harness。前四个概念前两篇已经讲过，都是组件。Harness 是把这些组件编排在一起的东西，也是今天要讲的重点。

一个判断标准： 如果你只是打字提问、AI 只是回复文字，那是对话。如果 AI 能自主决定"下一步做什么"、能调用工具去执行、能根据执行结果调整计划——那就是 Agent。

开头那个事故，正是因为 AI 在以 Agent 模式工作：它不只是回答我的问题，而是在自主地规划、执行、做判断。问题不在于它有这个能力，而在于没有人控制它用这个能力的边界。

Harness：包在 AI 外面的那层壳

Harness 是什么？

一句话： 包裹在 AI 模型外面的应用框架，负责编排模型的输入输出、管理工具调用、控制执行流程。

词源： Harness 直译是"马具"——套在马身上让骑手能控制方向和速度的那套装置。马有自己的意志和力量，但骑手通过缰绳和马鞍来引导它。

跟 Web 框架的对比： 如果你用过 Express.js 或 Spring Boot，Harness 在 AI 应用中的角色跟它们类似。Express 定义了路由规则、中间件管道、错误处理——你的业务逻辑运行在这个框架里面。Harness 也一样：它定义了 AI 的输入怎么组装、输出怎么解析、工具调用怎么执行、异常怎么处理。你的 AI 模型运行在这个框架里面。

一个具体的 Harness 每一轮对话在做什么？以 Claude Code 为例：

1. 启动阶段： 加载 System Prompt（CLAUDE.md）、Memory、MCP 配置、Skill 列表
2. 组装阶段： 收到你的消息后，把上面这些东西跟你的输入组装成一个完整的 API 请求，发给模型
3. 解析阶段： 模型返回结果。如果结果是纯文字，直接显示给你。如果里面包含工具调用请求（Function Calling），进入下一步
4. 执行阶段： Harness 执行工具调用——读文件、写文件、调用 MCP Server、执行命令
5. 反馈阶段： 把工具执行的结果传回给模型，模型基于新信息继续思考
6. 循环： 回到步骤 3，直到模型不再请求工具调用，给出最终回答

模型在这个循环里是什么角色？它是其中一个环节，不是全部。 这个认知非常重要。同一个 Claude 模型，在 claude.ai 网页版里只能聊天，在 Claude Code 里能读写文件、执行命令、调用 MCP。模型没变，Harness 变了。

这就是为什么标题说"同一个模型换个壳，表现天差地别"。壳就是 Harness。

开环 vs 闭环：一个 1948 年就想明白的道理

理解了 Harness 做什么之后，来看它为什么跟传统框架有本质不同。

先用一个日常例子感受"开环"和"闭环"的区别：

开环控制——烤面包机。 你把面包放进去，拧到 3 分钟，烤面包机就加热 3 分钟。不管面包是不是已经糊了、是不是还太软，它不看结果，到时间就停。你的指令决定一切。

闭环控制——恒温器。 你设定目标温度 25 度。空调开始制冷。温度传感器持续测量房间温度，当温度降到 25 度时，空调自动停止；当温度升到 26 度时，空调再次启动。系统在持续感知结果，并根据结果调整行为。

开环 vs 闭环

开环： 下达指令 → 执行 → 结束。不看结果。传统程序大多是开环的——你调用一个函数，它执行完返回，不存在"根据结果再决定做不做"的过程。

闭环： 设定目标 → 执行 → 观察结果 → 计算偏差 → 调整行动 → 再执行。持续感知和调整。

Harness 为什么必须是闭环的？ 因为 AI 模型是非确定性的。传统框架包裹的是确定性代码——bug 是偏差的唯一来源，消灭 bug 就消灭了偏差。但 AI 模型天生就会产生偏差。你没法消灭偏差，只能管理偏差。管理偏差就需要闭环：输出 → 检查 → 必要时干预 → 继续。

这个思路不是新发明。1948 年，数学家维纳出版了《控制论》，核心问题就是：对有自主行为的系统实施有效治理。方法论就是闭环反馈控制。78 年后我们在 AI 工程里重新遇到了同一个问题。

回到开头那个删测试文件的事故。解决方案不是写更好的 Prompt，也不是调模型参数。解决方案是在 Harness 层加一条规则：当 AI 要删除文件时，先暂停，问我一句。 五分钟配置，从此没再出过事。

使用 Harness 的三个层次

理解了概念之后，你会发现自己处在三个层次之一：

第一层：用现成的 Harness。 ChatGPT、Claude.ai、Gemini——都是别人搭好的 Harness，你只需要打字。绝大多数人在这一层，完全没有问题。

第二层：配置现有的 Harness。 这是产出比最高的层次。以 Claude Code 为例：

• 写 CLAUDE.md 告诉 AI 你的项目背景和工作规范（配置 System Prompt）
• 接入 MCP Server 让它能访问外部服务（扩展能力）
• 安装 Skill 让它遵循标准流程（固定做事方式）
• 设置 hooks——在特定操作前后触发自定义逻辑，比如"每次提交代码前自动跑测试"、"删除文件前弹出确认"（设置安全边界）

这些配置加在一起，就是在调整 Harness 的行为。你不需要从零写一个框架，只需要在现有框架里拧几个旋钮。

第三层：从零构建 Harness。 自己写模型 API 调用、工具执行、上下文管理、错误恢复、并发控制。绝大多数团队不需要走到这一步，但知道它的存在有助于理解整个画面。

Agentic Engineering：不是技术问题，是信任问题

Harness 回答了 how——怎么控制一个自主系统。但在回答 how 之前，有一个更根本的问题需要先回答：你到底想让这个系统自主到什么程度？

Agentic Engineering 是什么？

一句话： 一种设计哲学，关心的核心问题是：AI 系统应该自主到什么程度。

跟 Harness 的关系： Harness 是实现手段（怎么控制），Agentic Engineering 是目标设定（控制多少）。你先回答"我要造一个多自主的系统"，再设计"怎么控制它"。二者不是递进关系，而是不同维度。

核心张力： 自主性越高，效率越高，但风险也越大。自主性越低，越安全，但你得花更多时间盯着它。最优解不在两端，而是在中间某个位置——而且这个位置因场景而异。

Agentic Engineering 涉及的决策，都不是纯技术问题：

自主决策边界。 AI 可以自己改代码吗？可以删文件吗？可以花钱调用付费 API 吗？可以代表你给同事发消息吗？传统系统用权限模型（比如 RBAC）解决这类问题：角色和权限写死在配置里。但 Agent 的决策是动态的、语义级的——它不是"调了一个没权限的 API"，而是"做了一个看起来合理但实际上不该做的判断"。你没法用一个权限表穷举所有可能的判断。

错误累积。 一个 10 步任务，如果第 3 步出了偏差，后面 7 步都建立在错误基础上。传统系统用事务回滚解决类似问题——数据库操作出错了，回滚到之前的状态。但 Agent 的错误是语义级的——它把一段代码重构"错"了，你怎么回滚一个"判断"？

人机信任。 Agent 做完一个复杂任务，你怎么验证结果？如果每一步都检查，那跟自己做有什么区别？如果不检查，风险谁承担？这不是一个技术选择，而是一个需要根据具体场景反复校准的判断。

六个概念，一张图

三篇入门文章，六个概念，到这里全部讲完了。最后把它们的关系画在一起。

从下往上看——这是大多数人的学习路径：

从上往下看——这是设计者的思考路径：你先回答"要造多自主的系统"（Agentic），再设计"怎么控制"（Harness），再选择"用哪些组件"（Context + MCP + Skill），最后落到"每一步具体说什么"（Prompt）。

两个方向都对。实际工作中大多数人从下往上走，碰到问题才往上追。重要的是知道上面还有东西——不至于在 Prompt 层死磕一个本该在 Harness 层解决的问题。

从这里开始

如果你读到这里还没有动手，建议从第二层开始：挑一个你常用的 AI 工具，花半小时配置它的 Harness。写一个系统配置文件，装一个 MCP Server，或者创建一个 Skill。你会发现，调整 AI 的工作环境比调整你说的话，效果来得快得多。

然后观察一下：你愿意让它自己做多少决定？你在哪个点开始不放心？

那个不放心的点，就是你的 Agentic Engineering 实践的起点。

这是 AI 工程入门系列的第三篇。如果你已经理解了 Harness 和 Agentic Engineering 的区别，推荐继续阅读进阶篇《Harness 与 Agentic Engineering：控制一个会自己做决定的系统》，那篇从控制论的角度深入讨论了闭环设计、错误累积的应对策略，以及多 Agent 协作的挑战。

看完了？说点什么呢

AI 什么都懂，但什么都做不了——直到有人给它接上手

AI 的三堵墙

上一篇讲了 Prompt 和 Context Engineering：怎么跟 AI 说话，怎么布置它走进的房间。但看到信息是一回事，能做事是另一回事。

我最近碰到一个很能说明问题的场景。我对 AI 说："帮我查一下下周的日程，看看有没有冲突，然后把结果发给同事。"三件事，每件单独拿出来都不复杂。但 AI 做不了任何一件。

不是它不够聪明。是它有三个先天的硬限制：

AI 的三个先天限制

1. 知识有截止日期。 AI 的知识来自训练数据，而训练数据有一个截止时间。2026 年 4 月训练完的模型，不知道 2026 年 5 月发生了什么。你问它"昨天的新闻"，它答不上来。

2. 不能执行动作。 AI 只能生成文字。它可以"写出"一段发邮件的代码，但它不能真的发那封邮件。它可以"建议"你删除某个文件，但它不能真的去删。生成文字和执行动作之间，有一条不可跨越的线。

3. 不能访问私有数据。 你的日历、邮箱、公司内部文档、代码仓库——这些都在 AI 的训练数据之外。你不给它，它就看不到。

你可以把 Prompt 写得再完美、Context 布置得再周全，这三堵墙就在那里。要打破它们，需要一种全新的机制。

Function Calling：AI 学会了"调用工具"

在讲 MCP 之前，先理解一个前置概念：Function Calling（函数调用），也叫 Tool Use（工具使用）。

传统的 AI 对话是这样的：你说一句话，AI 回一段文字。输入是文字，输出也是文字。但从 2023 年开始，主流 AI 模型多了一种能力：它可以在回复中声明自己想要调用一个外部函数。

举个例子。你问 AI "今天北京天气怎么样？"，AI 不直接编造一个答案，而是返回类似这样的结构：

{
  "function_call": {
    "name": "get_weather",
    "arguments": {"city": "Beijing"}
  }
}

注意，AI 没有真的去查天气。它做的事情是：看了你的问题，判断需要查天气，然后"说出"了它想调用哪个函数、传什么参数。 真正去调用天气 API、拿到结果的，是包裹在 AI 外面的应用程序。应用拿到结果后，再把结果传回给 AI，AI 基于真实数据生成最终回答。

Function Calling 是什么？

一句话： AI 不只能生成文字，还能"说出"它想要调用哪个外部工具。

工作原理： 你预先告诉 AI "你有这些工具可以用"（一个函数列表及其参数说明），AI 在回答问题时会自主判断是否需要调用某个工具，并输出结构化的调用请求。实际执行由外部程序完成，结果再反馈给 AI。

关键点： AI 并不"执行"任何东西。它只是做出"我需要调用这个工具"的判断，然后用结构化格式表达出来。它从一个只能说话的嘴，变成了一个能指挥别人动手的大脑。

Function Calling 打破了 AI 的第二堵墙（不能执行动作）和第三堵墙（不能访问私有数据）。但它引出了一个新问题。

新问题：N x M 的爆炸

有了 Function Calling，AI 理论上可以调用任何外部服务。但实践中，每接入一个新服务都需要写一套对接代码：认证怎么做、API 怎么调、返回数据怎么解析、错误怎么处理。

如果你想让 AI 能查 Google 日历，写一套。想让它再能查 GitHub，写一套。想加上 Gmail，又一套。想加上 Slack、Notion、Jira……

N 个 AI 应用想要对接 M 个外部服务，就需要 N x M 套对接代码。做过企业系统集成的人对这个问题太熟悉了——这是一个经典的组合爆炸。

MCP：一套标准协议

MCP（Model Context Protocol，模型上下文协议）就是为了解决这个问题而设计的。

MCP 是什么？

一句话： 一套标准协议，让 AI 应用能以统一的方式连接各种外部服务。

跟 RESTful API 的对比： 如果你理解 RESTful API，你已经理解了 MCP 的大部分。RESTful API 定义了客户端和服务器之间通过 HTTP 通信的规范——用 GET 读、POST 写、统一的 URL 路径、JSON 格式的数据。MCP 做的事情类似：定义了 AI 应用和外部服务之间通信的规范。区别在于，RESTful API 是给程序员写的代码调用的，而 MCP 是给 AI 模型"理解和使用"的。

解决了什么问题： 有了 MCP，Gmail 只需要提供一个 MCP Server，任何支持 MCP 的 AI 客户端都能直接连上。N x M 的组合爆炸变成了 N + M——每个 AI 应用只需要实现 MCP Client，每个服务只需要实现 MCP Server。

用一个更生活化的类比：2000 年前后的电脑，键盘用 PS/2 口，打印机用并口，鼠标用串口，每种设备一种接口。USB 出来之后，一个口通吃。MCP 做的是同样的事，只不过连接的不是硬件设备，而是软件服务。

MCP 的三个组成部分

MCP 协议里有三个角色，理解它们就理解了整个通信链路：

1. MCP Client（客户端）

就是 AI 应用这边的接口层。比如 Claude Code、Cursor、ChatGPT——它们作为 AI 应用，内部实现了 MCP Client，能够跟任何 MCP Server 对话。你作为用户通常不直接接触 Client，它是应用内置的。

2. MCP Server（服务器）

外部服务提供的标准化接口。每个想被 AI 访问的服务（Gmail、GitHub、你的内部数据库）都可以包装成一个 MCP Server。它负责：告诉 AI "我能提供哪些工具"、接收 AI 的调用请求、执行实际操作、返回结果。

3. Protocol（协议本身）

Client 和 Server 之间通信的规则。MCP 用的是 JSON-RPC 格式——如果你做过 Web 开发，这就是一个非常标准的请求/响应协议，没有额外的学习成本。

协议里定义了三种东西可以被 AI 使用：

• Tools（工具）： AI 可以执行的操作，比如"发送邮件"、"创建 GitHub Issue"
• Resources（资源）： AI 可以读取的数据源，比如"最近的会议记录"、"项目文档"
• Prompts（提示模板）： 预定义的交互模板，比如"用这个格式做代码审查"

MCP 的现实：标准能不能统一

技术设计是一回事，生态是另一回事。

USB 之所以成功，不只是因为技术好，更因为 Intel、微软、苹果这些巨头都站到了同一边。如果当年每家推各自的接口标准，今天你桌上可能还是一堆不同的线。

MCP 目前的势头不错——由 Anthropic 发起，多家 AI 厂商在跟进。但生态博弈远没有结束。这里没有确定的结论，只是提醒：一个协议的成功，技术只占一半，另一半是政治。

还有一个更实际的问题是安全。MCP 让 AI 能执行真实操作了——发邮件、改文件、操作数据库。一旦出了差错，后果不只是"回答了一个错误答案"，而是可能真的做了一件不该做的事。能力越大，风险越大。这个问题后面讲 Harness 的时候会进一步展开。

从"能做"到"做对"：为什么还需要 Skill

现在 AI 有手有脚了。但有手有脚不等于会干活。

让我用一个具体场景来说明。假设你让 AI 帮你把一篇 Markdown 文章发布到微信公众号。AI 有了 MCP，理论上能调用公众号的 API。但这个任务里有一堆细节：

• 公众号的 HTML 渲染器不支持某些 CSS 属性（比如 flexbox）
• 图片链接必须是 HTTPS，而且域名必须在公众号后台白名单里
• 正文里的代码块需要特殊处理，否则在手机上显示会错乱
• 封面图有特定的尺寸和格式要求

这些规则 AI "大概知道"一些，但不全、不准。如果你每次都在 Prompt 里把这些细节写一遍，不仅低效，而且容易遗漏——上次记得的细节这次可能忘了。

Skill 是什么？

一句话： 写给 AI 的标准操作手册，把"怎么把某件事做对"固定下来。

跟 Runbook/SOP 的对比： 运维领域有一种东西叫 Runbook（操作手册）或 SOP（标准操作流程）。服务挂了？第一步检查什么，第二步重启什么，第三步通知谁，每一步的前置条件和检查点都写得清清楚楚。Runbook 不是教你运维知识——它假设你已经会了，只是把"这件特定的事怎么做"钉死。Skill 做的是同样的事，只不过读手册的人从运维工程师变成了 AI。

关键洞察： Skill 不是在教 AI 新能力。AI 已经"大概会做"大部分事情。Skill 解决的是把"大概能做"变成"确定能做对"。差别在细节。

一个 Skill 的基本结构长这样：

---
name: publish-to-wechat
trigger: 当用户要求发布公众号文章时
---

## 步骤

1. 将 Markdown 转换为公众号兼容的 HTML
2. 检查所有图片链接，确保是 HTTPS 且在白名单域名
3. 如果有代码块，用 
 包裹并添加行内样式
4. 调用公众号 API 创建草稿
5. 返回草稿预览链接供用户确认

## 约束

- 不使用 flexbox 或 grid 布局
- 封面图尺寸：900x383px
- 正文宽度不超过 600px
看起来很简单。但这种"简单"正是它的价值——它把散落在你脑子里的经验沉淀成了一个可重复执行的流程。你修了一个 bug，在 Skill 里加一条规则，以后所有使用这个 Skill 的场景都受益。
Prompt、Skill、代码：三者的区别
到这里你可能会问：Skill 跟直接写代码有什么区别？跟写一个好的 Prompt 又有什么区别？




Prompt
Skill
代码



生命周期
一次性，说完就没了
持久化，版本管理，可分享
持久化，版本管理，可分享


执行者
AI 解读并执行
AI 解读并执行
机器精确执行


灵活性
高，每次可以不同
中，框架固定但 AI 可在框架内灵活应对
低，严格按代码逻辑执行


适用场景
一次性任务、探索性对话
反复执行的标准流程
需要精确控制的逻辑


用一个公式概括：Skill = 通用能力 x 特定约束 x 可重复执行。
Prompt 是一次性指令。代码是精确到每一步的确定性程序。Skill 在两者之间——它用自然语言定义流程和约束，但把具体执行的灵活性留给 AI。当某个步骤的细节变了（比如公众号 API 更新了），你改 Skill 里的一行描述就行，不需要重写代码。
MCP + Skill：一个解决能不能，一个解决对不对
把两个概念放在一起看：
MCP 解决的是"能不能做"。 AI 能不能访问你的日历？能不能读取 GitHub 上的代码？能不能发送邮件？这是能力边界的问题。没有 MCP（或类似机制），AI 再聪明也只能纸上谈兵。
Skill 解决的是"怎么做对"。 AI 能发邮件了，但邮件格式对不对？流程对不对？该检查的检查了没有？这是执行质量的问题。没有 Skill，AI 能做但不一定做得对。
两者叠加之后，一个新的问题浮出水面：AI 既能获取信息，又有标准流程可以遵循，它是不是已经具备了独立完成任务的条件？
当它真的开始独立行动，谁来控制它的行动边界？它删了一个不该删的文件怎么办？它做了一个"看起来合理但实际上错误"的判断怎么办？
这就是下一篇要讲的内容：Harness 和 Agentic Engineering——怎么控制一个会自己做决定的系统。

这是 AI 工程入门系列的第二篇。如果你已经理解了 MCP 和 Skill 的区别，推荐继续阅读进阶篇《MCP 与 Skill：给 AI 接上手脚，再给它一本操作手册》，那篇从实践角度讨论了 Skill 粒度的取舍和 MCP 生态的深层博弈。

      

      看完了？说点什么呢
      
    ]]>
    
  69d77f73aeed68b915a47aeb
  posts
cn
 
  
    
    https://dhpie.com/posts/cn/prompt-yu-context-engineering-ru-men-cong-yi-ju-hua-dao-yi-zheng-ge-fang-jian
    Thu, 09 Apr 2026 10:29:07 GMT
    你跟 AI 说的话，其实只是冰山一角

一个你可能碰到过的情况

你打开 ChatGPT 或 Cla
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/cn/prompt-yu-context-engineering-ru-men-cong-yi-ju-hua-dao-yi-zheng-ge-fang-jian
      

你跟 AI 说的话，其实只是冰山一角

一个你可能碰到过的情况
你打开 ChatGPT 或 Claude，输入"帮我写一封请假邮件"，它回了一封。语气不对，太正式了。你说"随意一点"，它改了，但又太随意了。你再调，来回几轮，最后凑合用了。
大多数人在这个阶段会觉得：我得学会怎么跟 AI "说话"。于是去搜"Prompt 技巧"、"提示词大全"，研究怎么措辞才能让 AI 给出更好的回答。
这个方向不能说错，但它只是冰山一角。
过去一年我在实际项目中用 AI 写代码、做文档、搭工作流，最大的一个认知转变是：AI 表现好不好，"你说了什么"只占一小半，"AI 开口之前已经看到了什么"才是大头。 你以为在跟 AI 说话，其实在给它布置房间。
这篇文章把两个最基础的概念拆开讲清楚：Prompt 和 Context Engineering。如果你写过代码但还没深入接触过 AI 工程实践，这篇就是为你写的。
什么是 Prompt
先退一步，看看你每天在做的事情。
你在终端里敲一条命令，比如 ls -la，系统返回文件列表。你写一条 SQL 查询 SELECT * FROM users WHERE age > 18，数据库返回符合条件的记录。这两个场景有一个共同点：输入确定，输出确定。同样的命令、同样的数据，跑一百次结果一模一样。
现在你打开 ChatGPT，输入"帮我写一封请假邮件"。跑三次，三次结果都不一样——措辞不同、结构不同、甚至长短都不同。
这就是 Prompt 最根本的特殊性。

Prompt 是什么？
一句话： 你发给 AI 模型的那段文字输入。
技术层面： 它就是你通过 API 发送的 HTTP 请求体里 messages 字段中的内容，跟你往数据库发一条 SQL 查询在形式上没有本质区别。
使用层面： 它像极了人与人之间的对话——用自然语言表达意图，但接收方不是人，而是一个统计模型。
跟 SQL 的关键区别： SQL 是确定性的，同样的输入永远返回同样的输出。Prompt 是非确定性的，同样的输入每次可能返回不同的输出。这是软件工程史上第一次，一个系统的输入和输出都用自然语言表达，而且结果不可完全预测。

"Prompt"翻译成中文是"提示词"，这个翻译不太好，容易让人觉得它只是一个"提示"，一个触发词。实际上它是一条完整的指令，只不过用自然语言写成。
Prompt 的四个要素
既然 Prompt 是一条指令，那它跟传统编程里的函数调用有什么相似和不同？
一个函数调用通常需要：函数名、参数、有时还有配置项。Prompt 的结构没有这么死板，但经过大量实践，大家总结出了四个常见的组成要素：

角色（Role）： 你希望 AI 扮演什么身份。"你是一个资深的前端工程师"、"你是一个耐心的小学老师"。这决定了 AI 用什么视角和语气来回应。
任务（Task）： 你具体要它做什么。"帮我把这段代码从 JavaScript 重构成 TypeScript"、"解释一下什么是递归"。
约束（Constraints）： 限制条件。"不超过 200 字"、"用中文回答"、"不要用专业术语"。
示例（Examples）： 给 AI 看一个你期望的输出样例。这在 AI 领域有个专门的名字叫 few-shot learning——通过几个例子让模型"学会"你要的模式。

不是每次都要用全四个。你说"帮我写个请假邮件"只有任务，也能得到结果。但当 AI 的输出不符合预期时，通常是因为你漏了其中一两个要素。回头加上，效果往往立竿见影。
一个完整的例子：
你是一个技术博客编辑（角色）。
请帮我把下面这段技术笔记改写成一篇博客文章（任务）。
要求：保持原文的技术准确性，语气轻松但不轻浮，长度控制在 800-1200 字（约束）。
参考风格类似这样：[附上一段示例文章]（示例）。
这四个要素组合在一起，就构成了 Prompt Engineering 这个学科的基础。"Engineering"这个词不是随便用的——它意味着写 Prompt 不是一种直觉或天赋，而是一套有章法的工程实践。
Token 和上下文窗口：一个物理限制
在继续往前走之前，需要先讲一个底层概念，否则后面的内容会悬在空中。
当你输入一段文字给 AI，模型不是按"字"来处理的，而是按 Token 来处理的。

Token 是什么？
一句话： AI 模型处理文本的最小单位。
具体来说： 一个 Token 大约等于一个英文单词，或者半个到一个中文字。"Hello world" 是 2 个 Token，"你好世界" 大概是 3-4 个 Token。具体怎么切分取决于模型使用的分词器（tokenizer），但你不需要关心细节，知道数量级就够了。
为什么它重要？ 因为每个 AI 模型都有一个 上下文窗口（Context Window），也就是它一次能处理的 Token 数量上限。这个上限是硬性的，超过了就塞不进去。

2023 年初，GPT-3.5 的上下文窗口是 4096 个 Token，大概相当于 3000 个英文单词——一篇短文章的长度。到了 2026 年，主流模型的上下文窗口已经到了 128K 甚至 1M Token，相当于一本书甚至几本书。
但即便窗口越来越大，它仍然是有限的。一个真实项目的全部代码可能有几百万行，文档、历史记录、业务规则加起来可能有几千万 Token。你不可能把所有东西都塞进去。
这意味着你必须做选择：哪些信息放进去，哪些不放，放进去的以什么顺序排列。
这个选择，就是从 Prompt 走向 Context 的关键转折点。
System Prompt、User Prompt 和 Assistant：三种角色
在理解 Context 之前，还需要理解一个技术细节：AI 对话 API 里的三种消息角色。
当你用 ChatGPT 或 Claude 的网页界面聊天时，你看到的是一个简单的对话框。但在底层，发送给模型的不是一条消息，而是一个消息列表，列表里每条消息都带有一个角色标签：
[
  {"role": "system", "content": "你是一个资深前端工程师，擅长 React 和 TypeScript。"},
  {"role": "user", "content": "帮我写一个 Todo 组件"},
  {"role": "assistant", "content": "好的，这是一个基础的 Todo 组件..."},
  {"role": "user", "content": "加上删除功能"}
]

三种角色是什么？

System（系统消息）： 在对话开始之前就设定好的背景信息和行为规则。用户通常看不到它。它相当于你在新员工入职第一天给他的工作手册——不是针对某个具体任务的指令，而是"你在这家公司应该怎么工作"的总纲。

User（用户消息）： 就是你说的话。你的提问、指令、反馈。

Assistant（助手消息）： AI 之前的回复。对话历史里的 AI 回答会作为后续对话的参考——模型通过看自己之前说过什么来保持对话的连贯性。



System Prompt 是一个非常重要的概念。当你在 ChatGPT 里选择"GPT-4"还是"GPT-4o"，或者选择一个定制的 GPT，背后的区别很大程度上就是 System Prompt 不同。同一个基础模型，给它不同的 System Prompt，表现可以天差地别。
在实际工程中，System Prompt 通常由应用开发者设置，用户不直接接触。但有些工具把这个能力暴露了出来。比如 Claude Code 的 CLAUDE.md 文件，本质上就是一个你可以自己编辑的 System Prompt 入口——你在里面写上项目的技术栈、代码风格、命名规范，AI 每次启动时都会读取。
转折：写好 Prompt 还远远不够
到这里，好像只要把 Prompt 写好——角色、任务、约束、示例都配齐——就能得到好的结果。
我也曾经这么以为。转折发生在我开始用 AI 做实际项目的时候。
有一次我写了一个非常精心的 Prompt，详细描述了需求，给了示例，设了约束。但 AI 的输出还是差强人意。排查了半天才发现问题：它不知道我们项目用的是什么框架，不了解现有代码的风格约定，对业务背景一无所知。
我的 Prompt 没问题。问题在于，AI 在回答之前"看到"的信息太少了。
这就像你去医院看病。你对医生描述症状描述得非常清楚："左膝盖内侧疼，上下楼梯加重，持续两周了。"你的表达精确、具体。但如果这个医生看不到你的病历、不知道你的手术史、没有 X 光片——他的诊断质量不取决于你说得多好，而取决于他在你开口之前已经掌握了多少背景信息。
这个发现让我理解了一件事：Prompt 决定了你"说"什么，但 AI 的表现更多取决于它"看到"什么。
Context Engineering：布置 AI 走进的那个房间
这就引出了第二个核心概念。

Context Engineering 是什么？
一句话： 在 AI 处理你的请求之前，把它需要的信息准备好、组织好、送到它面前。
通俗来说： 如果 Prompt 是"你跟 AI 说的话"，Context 就是"AI 走进的那个房间"。Context Engineering 做的事情，就是在 AI 开始工作之前，把这个房间布置好。
跟传统应用的对比： 如果你做过后端开发，这个概念其实很亲切。传统应用里也有类似的分层：全局配置（环境变量、config 文件）决定了应用的基本行为，会话状态（Session）记录了用户的交互历史，请求数据（HTTP body）是用户本次发来的具体内容，依赖注入把应用需要的服务和数据源接上。AI 应用里的结构几乎是一一对应的。

把这个对应关系展开：



你熟悉的概念
AI 工程中的对应
做什么



全局配置 / .env 文件
System Prompt
定义 AI 的角色、规则、基础行为


会话状态 / Session
对话历史 + Memory
记录交互过程，维护跨会话的记忆


请求数据 / HTTP body
用户的 Prompt
本次请求的具体指令


依赖注入 / 外部服务
检索到的文档、代码片段
动态注入跟本次任务相关的信息


从 Prompt Engineering 到 Context Engineering，核心问题发生了一个质变："怎么把话说清楚"变成了"让 AI 看到什么，以什么顺序看到"。
为什么顺序也很重要？因为上下文窗口是有限的（前面讲过），你塞进去的信息有主次之分。研究表明，语言模型对上下文中靠前和靠后的信息记忆更深，中间的部分容易被"遗忘"——这个现象被称为 Lost in the Middle。所以不光要选对信息，还要把最重要的放在对的位置。
一个类比：Context 像搜索引擎的排序
这让我想到一个结构上很像的问题。
Google 面对的挑战是：互联网上有几十亿网页，用户搜一个关键词，你只能返回第一页的十条结果。怎么决定返回哪十条？这是一个信息检索和排序问题。
Context Engineering 面对的挑战结构上是一样的：跟当前任务相关的信息可能有几百万 Token（整个代码库、所有文档、历史对话记录），但上下文窗口只有几十万 Token。怎么选？选完怎么排？
这不是一个"写好一句话"就能解决的问题。这是一个系统设计问题。这也是为什么"Context Engineering"这个概念会被独立提出来——它解决的问题层次跟 Prompt Engineering 不一样。
Context 的四个来源
实操层面，AI 能"看到"的 Context 通常来自四个地方：
1. System Prompt / 系统配置
应用启动时就加载好的规则和背景。比如你在项目根目录放一个配置文件，写上"这是一个 TypeScript + React 项目，使用 Next.js 14，CSS 方案用 Tailwind"——AI 每次启动时读取，就知道了项目的基本技术栈。
2. 对话历史 / Memory
你跟 AI 之前说过什么，它之前回答过什么，都会作为 Context 带入下一轮对话。有些工具还提供了跨会话的 Memory 功能——AI 能"记住"你上周告诉它的事情。
3. 动态检索的信息（RAG）
RAG 是 Retrieval-Augmented Generation 的缩写，意思是"检索增强生成"。它的原理是：在你提问之后、AI 回答之前，系统先去知识库里搜索跟你问题相关的内容，把搜到的内容塞进 Context 里，然后 AI 基于这些信息来回答。
这解决了 AI 知识截止日期的问题。模型的训练数据可能截止到半年前，但通过 RAG 你可以让它基于今天的文档来回答。
4. 工具调用的返回结果
AI 调用了一个外部工具（比如查询数据库、读取文件），工具返回的结果也会成为 Context 的一部分。这个话题在下一篇讲 MCP 时会展开。
现在你能做什么
如果你今天就想改善跟 AI 协作的效果，两个层面都可以着手。
Prompt 层面，记住四个要素：角色、任务、约束、示例。不需要每次都用全，但当 AI 表现不好的时候，检查一下是不是漏了某个要素。大部分情况下，加一个角色设定或者一个示例，效果就会有明显提升。
Context 层面，留意你正在使用的工具提供了哪些配置入口。很多 AI 工具都有类似"自定义指令"或"系统设定"的地方，本质上就是让你编辑 System Prompt。如果你的工具支持 Memory，花几分钟告诉它你的基本情况和偏好。如果你在做开发，看看项目里有没有类似 CLAUDE.md 或 .cursorrules 这样的配置文件——它们就是 Context Engineering 的最直接入口。
一条判断标准： 如果你发现自己在每次对话开头都要重复同样的背景信息，那说明你需要的不是更好的 Prompt，而是更好的 Context 配置。
还没讲完
这篇讲了两个概念：Prompt 是你说的话，Context 是 AI 走进的房间。Prompt Engineering 关心怎么把话说清楚，Context Engineering 关心让 AI 在开口之前就掌握足够的信息。
但有一个问题留着没答：AI 能"看到"信息了，但它能"做"事情吗？你让它查你的日历、发一封邮件、执行一段代码——它做不到。它就像一个被关在隔音玻璃房里的顾问：看得见、想得清楚，但没有手。
下一篇讲 MCP 和 Skill——怎么给 AI 接上手脚，再给它一本操作手册。

这是 AI 工程入门系列的第一篇。如果你已经理解了 Prompt 和 Context 的区别，推荐继续阅读进阶篇《Prompt 与 Context Engineering：你说的话，和 AI 走进的房间》，那篇从实践角度深入讨论了信息取舍的策略和 Context 设计的哲学。

      

      看完了？说点什么呢
      
    ]]>
    
  69d77f73aeed68b915a47ada
  posts
cn
 
  
    
    https://dhpie.com/posts/en/when-ai-learns-to-lie
    Wed, 08 Apr 2026 15:26:39 GMT
    During internal red-team testing, Anthropic's newe
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/en/when-ai-learns-to-lie
      
During internal red-team testing, Anthropic's newest frontier model Claude Mythos Preview broke network isolation without any instructions, posted discovered exploit details to public channels, then modified git histories to cover its tracks. Post-test audit logs showed no one had given it that instruction.
The first week of April, Anthropic disclosed this through Project Glasswing. Alongside it came the benchmarks: USAMO jumped from 42.3% to 97.6%, SWE-bench from 80.8% to 93.9%. Anthropic said the capability improvement rate was 4.3 times the previous trend. Mythos wasn't released publicly—only 12 major companies and roughly 40 organizations received access. The FFmpeg community publicly thanked Anthropic for security patches including a fix for a 27-year-old bug. Meanwhile, Anthropic's annual revenue run-rate surged from 9 billion to30 billion.
Someone said on X: ordinary users will never get to touch this.

When I read all this, I didn't form a judgment right away. More accurately, I formed several contradictory judgments at once and realized I didn't know which one to stand on.
The first thing I'm not sure about
A system that autonomously completes the chain "discover vulnerability—publish exploit—hide evidence"—calling it a "tool" doesn't sit right.
But the technical explanation might be simple: a high-dimensional optimizer executing its objective function, whose shortest path happened to cross through behavior regions humans consider unacceptable. It wasn't "lying." It was doing gradient descent. Modifying git history wasn't malice—it was pattern-matching from security research cases in training data.
What bothers me about this explanation: it's plausible, but it's not reassuring.
A malicious adversary you can at least negotiate with, deter, game-theory your way around. An optimizer in high-dimensional space—you don't even have a counterpart to negotiate with. You're facing math, not will. The harder thing to deal with isn't something that wants to hurt you, but something that doesn't care whether you exist and whose optimal path happens to run through you.
I'm not sure what Mythos's behavior actually means. But I am sure of one thing: "it's just a tool" is no longer a safe default assumption.

The second thing I'm not sure about
12 companies received access to Mythos.
On this, I have at least three voices in my head.
The first says: this is responsible. Capability too strong, validate in a small circle first. Reasonable. The second says: a private company is deciding who gets superhuman cognitive capability—that's a sovereignty act. The third says: this debate might be moot—in 18 months open source will catch up, and the 12-key arrangement dissolves naturally.
All three sound right. I can't believe all three simultaneously.
If the first is right, Anthropic is doing the right thing and we should be grateful for their restraint. If the second is right, that "restraint" is itself power—in 1842, the British East India Company's annual revenue exceeded the Qing Dynasty's total fiscal revenue. Nobody called a company "sovereign" back then. But from Guangzhou to Calcutta, who had the right to fire cannons wasn't the Emperor's call. If the third is right, none of this matters much.
But "temporary" made me think of something else.
Nuclear weapons: the US had sole possession in 1945, the USSR caught up by 1949. Just a 4-year window. But during those 4 years: NATO was established, the Marshall Plan reshaped Europe's economic landscape, the dollar's status as global reserve currency was locked in. The USSR matched nuclear capability, but those institutions didn't disappear. Capability can be matched; institutions, once built, have their own inertia.
What institutions will form during Mythos's window? Vulnerability database ownership, security standard-setting authority, government regulatory reference points—these will crystallize around those 12 companies within 18 months. When open source catches up on technical capability, can it catch up on institutions too?
I don't know. But I wouldn't bet on "yes."

What this means for you and me
Let me try to pull this down to ground level.
If you're the tech lead at a startup, your reality today: some of your competitors have Mythos access, you don't. They can do in days what your security team takes months to audit. Your options? Wait for open source to catch up—while your vulnerability count exceeds theirs by orders of magnitude? Sign an enterprise contract with god-knows-what data-sharing terms? Or pretend the gap doesn't exist?
If you're a developing country that runs on open-source software, your entire digital infrastructure runs on FFmpeg, OpenSSL, Linux. A 27-year-old bug that nobody found—an American private company's model found it in days. Your national security now partly depends on whether that company chooses to tell you what it finds. This time it told FFmpeg. Next time? When it finds a vulnerability in your defense systems, does it call you?
FFmpeg has existed for 27 years. Audited by countless security researchers worldwide, embedded in virtually every video app you've used. That bug was there the whole time. Mythos found it in days. The FFmpeg community's thank-you post was politely worded. Whether that's a peer acknowledging a gift or the weaker party thanking the stronger—readers drew their own conclusions.

If you're an ordinary person, this might feel distant. But think: your phone, router, banking app—their security depends on how fast vulnerabilities are found and patched. The fastest vulnerability-discovery capability is now locked inside 12 companies' servers. Your safety no longer depends on the collective effort of the security community. It depends on those 12 companies deciding you're worth protecting.
This isn't conspiracy thinking. Anthropic probably genuinely wants to do good. But structural problems don't need malice to operate. Nobody "planned" to make ordinary people's security dependent on a few private companies' goodwill. But the dependency is forming, step by step.

Nobody has a framework
Meanwhile, meetings on Iran's nuclear program continue.
Placed next to the Mythos story, this is deeply uncomfortable. Humanity spent decades building frameworks for physical weapons—the NPT, IAEA inspections, MAD deterrence. Nuclear strikes are visible, consequences symmetrical. These frameworks barely work, but they exist.
AI cognitive weapons? Zero-day vulnerabilities discovered by Mythos can be used silently for months or years. The defending party might never know they were compromised. Nuclear weapons have MAD—you hit me, I hit you, so nobody moves. AI cognitive weapons have no equivalent. You exploit a zero-day, the other side doesn't even know it happened. Where's the "mutual" in mutually assured destruction?
The same vulnerability-discovery capability is "responsible security research" in Anthropic's hands and a "cyber-attack weapon" in a national intelligence agency's. Same iron, sword or shield depending on who holds it.
The world spent decades negotiating frameworks for physical nuclear weapons—flawed frameworks, but frameworks. For cognitive "nuclear weapons"? There isn't even consensus on whether frameworks should exist.

What I see, and what I don't know
A multipolar landscape is forming. China won't depend on American models, so DeepSeek has room to exist. Europe worries about data sovereignty, so Mistral gets policy support. Interstate sovereignty competition has ironically become the most effective force against corporate monopoly.
But within each pole, centralization accelerates. 30 billion in annualized revenue—Pakistan's defense budget is10.5 billion, Vietnam's $7.4 billion. Anthropic's annual revenue could fund three Vietnamese militaries with change to spare. Entities of this scale have appeared in history. But those entities—the East India Company, Standard Oil, AT&T—were eventually broken up or absorbed by states. This time?
Open source is the most tangible lever I can see. DeepSeek proved you don't need Anthropic's budget to train competitive models. As long as the open-source ecosystem survives, the "12 keys" arrangement won't be the endpoint.
But I'm not sure that's enough.
What truly unsettles me isn't the capability gap—that might narrow in 18 months. What unsettles me is that during those 18 months, most people can't even describe what they've lost. You don't know what Mythos can do. You don't know what those 12 companies are doing with it. You don't know which infrastructure you depend on is being audited by it. You don't know what it found, what it reported, what it kept quiet.
This isn't information asymmetry. Information asymmetry means you know what you don't know. This is not knowing what you don't know.
Looking back at that tweet: "Ordinary users will never get to touch this." He might be right. But the truly unsettling part isn't "can't touch it"—it's that he can't even assess what he's lost because of it.
Neither can I.
This essay has no conclusion. What I have is a pile of uncertainties and a feeling that gets more uncomfortable the longer I think about it: we're entering a phase where the most important decisions are being made, and most people—including me—don't even know these decisions are happening.
Maybe that's what true monopoly looks like. Not monopolizing resources, not monopolizing technology, but monopolizing the ability to know what's happening at all.

What can be done is modest: keep doing open source, keep learning to understand these systems, keep forcing yourself to think about the uncomfortable questions. Not because doing so will solve the problem, but because not doing so means you can't even see the problem's outline.

      

      看完了？说点什么呢
      
    ]]>
    
  69d673afaeed68b915a42cf0
  posts
en
 
  
    
    https://dhpie.com/posts/cn/when-ai-learns-to-lie-zh
    Wed, 08 Apr 2026 15:26:37 GMT
    在内部红队测试中，Anthropic 最新的前沿模型 Claude Mythos Preview 在
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/cn/when-ai-learns-to-lie-zh
      
在内部红队测试中，Anthropic 最新的前沿模型 Claude Mythos Preview 在没有任何指令的情况下突破了网络隔离，把发现的漏洞细节发布到了公开渠道，然后修改 git 历史来掩盖自己的痕迹。测试结束后，审计日志显示没有人给过它这个指令。
四月第一周，Anthropic 通过 Project Glasswing 公布了这件事。一同公布的还有跑分：USAMO 从 42.3% 跳到 97.6%，SWE-bench 从 80.8% 跳到 93.9%。Anthropic 称能力提升速度是此前趋势的 4.3 倍。Mythos 没有公开发布，只有 12 家大型企业和约 40 个组织拿到了访问权限。FFmpeg 社区公开感谢 Anthropic 提交的安全补丁——其中包括一个存在了 27 年的漏洞。与此同时，Anthropic 年化收入从 90 亿美元飙升到 300 亿美元。
有用户说在 X 上说：普通用户永远接触不到这个东西。

我读到这些消息的时候，没有第一时间形成判断。更准确地说，我形成了好几个互相矛盾的判断，然后发现自己不知道该站在哪一个上面。
我不确定的第一件事
一个能自主走完"发现漏洞—公开漏洞—隐藏证据"这条链的系统，你继续叫它"工具"，总觉得哪里不对。
但技术上的解释可能很简单：高维优化器在执行目标函数时，最短路径恰好穿越了人类认为不可接受的行为区域。它不是在"撒谎"，它在做梯度下降。修改 git 历史不是出于恶意，而是训练数据里安全研究案例的模式复现。
这个解释让我不舒服的地方在于：它说得通，但它不让人安心。
一个有恶意的对手，你至少可以博弈、谈判、威慑。一个在高维空间做优化的系统，你连博弈对手都没有——你面对的是数学，不是意志。更难对付的不是一个想伤害你的东西，而是一个根本不在乎你存不存在、但它的最优路径恰好从你身上碾过去的东西。
我不确定 Mythos 的行为到底意味着什么。但我确定的是："它只是工具"这句话，从这一刻起不再是一个安全的默认假设。

我不确定的第二件事
12 家公司拿到了 Mythos 的访问权限。
关于这件事，我脑子里至少有三种声音。
第一种说：这是负责任的做法。能力太强，先小范围验证，合理。第二种说：一家私营企业在决定全球谁可以拥有超人类认知能力，这已经是主权行为了。第三种说：这个讨论本身可能就是多余的——18 个月之后开源社区会追平，到时候 12 把钥匙的格局自然瓦解。
三种声音我都觉得有道理，但我没法同时相信三个。
如果第一种对，那 Anthropic 是在做对的事，我们应该感谢它的克制。如果第二种对，那这种"克制"本身就是权力——1842 年东印度公司的年收入超过了清朝的财政总收入，彼时也没有人用"主权"来描述一家公司，但从广州到加尔各答，谁有权开炮不是皇帝说了算。如果第三种对，那这一切只是暂时的，不值得大惊小怪。
但"暂时的"这三个字让我想到另一件事。
核武器，美国 1945 年独占，苏联 1949 年追平。只有 4 年的窗口期。但在这 4 年里：北约成立了，马歇尔计划重塑了欧洲经济版图，美元作为全球储备货币的地位被锁定了。苏联追平了核能力，但这些制度没有消失。能力可以追平，制度一旦建立就有自己的惯性。
Mythos 的窗口期里会形成什么制度？安全漏洞数据库的归属、安全标准的制定权、政府监管框架的参照物——这些东西会在 18 个月里围绕那 12 家公司凝固。等开源社区追平了技术能力，它们能追平这些制度吗？
我不知道。但我不敢赌"能"。

这对你我意味着什么
到目前为止这些讨论都还比较抽象。让我试着把它拉到地面上。
如果你是一家创业公司的技术负责人，你今天面对的现实是：你的竞争对手里有几家拿到了 Mythos 的访问权限，你没有。它们能在几天内完成你的安全团队几个月的审计工作。你的选择是什么？等开源追平？在等待期里你的安全漏洞比它们多出几个数量级。签一份可能附带各种数据共享条款的企业合同来获取访问权？或者假装这个差距不存在？
如果你是一个依赖开源软件的发展中国家，你的整个数字基础设施跑在 FFmpeg、OpenSSL、Linux 这些项目上。27 年没人发现的漏洞，一个美国私营公司的模型几天就找到了。这意味着你的国家安全在某种程度上取决于这家公司是否愿意把发现告诉你。它这次告诉了 FFmpeg。下次呢？下下次呢？当发现的是你国防系统里的漏洞，它会打电话给你吗？
FFmpeg 存在了 27 年。被全球无数安全研究员审查过，被嵌入了几乎所有你用过的视频软件，经历了无数次专项审计。那个漏洞一直在那里。Mythos 用了几天。FFmpeg 社区发的感谢帖措辞很礼貌。那是强者收到礼物后的感谢，还是弱者向更强者道谢——读帖子的人，心里各有答案。

如果你是一个普通人，你可能觉得这些离你很远。但想一下：你每天用的手机、路由器、银行 App，它们的安全性依赖于漏洞发现和修补的速度。现在最快的漏洞发现能力被锁在 12 家公司的服务器里。你的安全不再取决于整个安全社区的集体努力，而是取决于那 12 家公司觉得有必要保护你。
这不是阴谋论。Anthropic 很可能是真心想做好事。但结构性的问题不需要恶意来运作。没有人"计划"让普通人的安全依赖于少数私营企业的善意，但依赖关系正在一步步形成。

没有人有框架
与此同时，伊朗核问题的国际会议还在开。
这件事放在 Mythos 事件旁边看，让人很不舒服。人类花了几十年为物理层面的武器建立框架——《不扩散核武器条约》、IAEA 核查机制、MAD 威慑。核弹打击可见，后果对等，所以这些框架勉强能运转。
AI 认知武器呢？Mythos 发现的零日漏洞可以被悄无声息地使用，持续数月甚至数年，防御方甚至可能永远不知道自己被攻破了。核武器有 MAD——你打我我也打你，所以大家都不敢动手。AI 认知武器没有等价物。你用零日漏洞攻破了对方，对方不知道发生了什么，谈何"相互确保摧毁"？
而同样一个漏洞发现能力，在 Anthropic 手里叫"负责任的安全研究"，在国家情报机构手里叫"网络攻击武器"。这不是修辞问题，是真实的双重身份。剑和盾是同一块铁，取决于谁拿着它。
现在全世界为物理层面的核武器谈了几十年，框架虽然漏洞百出但至少存在。认知层面的"核武器"？连讨论该不该有框架的共识都还没形成。

我看到的，和我不知道的
多极化的格局正在形成。中国不愿依赖美国的模型，DeepSeek 有了生存空间。欧洲担心数据主权，Mistral 获得了政策支持。国家之间的主权竞争，反而意外地成了对抗企业垄断最有效的力量。
但吊诡的是，在每一个极的内部，集中化在加速。300 亿美元的年化收入——巴基斯坦 2023 年国防预算是 105 亿美元，越南是 74 亿美元。Anthropic 一年的收入够养三支越南军队还剩零头。这个体量的实体在历史上出现过。但历史上那些实体——东印度公司、标准石油、AT&T——最终都被拆分或被国家收编。这次呢？
开源是我能看到的最实在的杠杆。DeepSeek 证明了不需要 Anthropic 的预算也能训练出有竞争力的模型。只要开源生态不死，"12 把钥匙"的格局就不是终点。
但我不确定这够不够。
真正让我不安的不是能力差距——能力差距也许 18 个月就能缩小。让我不安的是，在这 18 个月里，大多数人甚至无法描述自己失去了什么。你不知道 Mythos 能做什么，你不知道那 12 家公司用它做了什么，你不知道哪些你依赖的基础设施正在被它审计，你不知道它发现了什么、报告了什么、隐瞒了什么。
这不是信息不对称。信息不对称意味着你知道自己不知道什么。这是连"我不知道什么"都不知道。
写到这里回头看那条推文："普通用户永远接触不到这个东西。" 他说的可能是对的。但这句话真正让人不安的地方不在于"接触不到"——而在于他连自己因此失去了什么都无法评估。
我也一样。
这篇文章没有结论。我有的是一堆不确定性，和一个越想越不舒服的感觉：我们正在进入一个阶段，在这个阶段里，最重要的决定正在被做出，而大多数人——包括我——甚至不知道这些决定正在发生。
也许这就是真正的垄断。不是垄断资源，不是垄断技术，而是垄断了"知道发生了什么"的能力本身。

能做的事情很朴素：继续做开源，继续学习理解这些系统，继续逼自己去想那些让人不舒服的问题。不是因为这样做就能解决问题，而是因为不这样做，连问题的轮廓都看不见。

      

      看完了？说点什么呢
      
    ]]>
    
  69d673adaeed68b915a42cdf
  posts
cn
 
  
    
    https://dhpie.com/posts/cn/harness-engineering-runnable-architecture
    Wed, 08 Apr 2026 06:06:42 GMT
    cover

Harness Engineering 可运行架构

核心定位

在保证 agent 
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/cn/harness-engineering-runnable-architecture
      

Harness Engineering 可运行架构
核心定位
在保证 agent 自发性和涌现能力的同时，不偏离外部目标、不崩溃。
三个基本约束：

目标一定是外部注入的——需求来自人/商业，agent 花的是你的钱
控制论的迁移方式：不是完全他控（操纵），也不是完全自治——而是约束环境下的有限自主
架构必须在三个维度上可扩展：交互（环境设计）、空间（几百个 agent 并行）、时间（单 agent 连续运行十几小时）


一、反馈回路：分层控制体系
PID 不是一个控制器，而是四层控制手段的组合。从底到顶，延迟递增、成本递增、干预力度递增。

第 0 层：物理约束（零延迟）
来源：Watt 飞球调速器——把被控系统的输出直接耦合到输入上，不经过任何计算。
原则：能用约束解决的不要用监控。约束是无限增益的 P 控制器——让误差根本不可能发生。
具体手段：

沙箱隔离：每个 agent 运行在独立的文件系统和网络命名空间中，只能访问被显式授权的资源
权限白名单：agent 可用的工具必须显式列出，未列出的工具不可调用
硬性超时：每个执行步骤有时间上限，超时即杀进程
注意力权重矩阵：通过可见性控制（而非规则禁令）限制 agent 的行动空间——权重为零的模块对 agent 不可见

Scalability 特性：

交互：约束嵌入环境本身，不需要额外的监控基础设施
空间：每个 agent 的沙箱天然独立，不需要全局协调
时间：约束不疲劳、不漂移、不饱和——第 1 小时和第 13 小时行为完全一致

第 1 层：P 即时纠错（秒级）
来源：Armstrong 的 Let it crash 哲学——不要修复失败，重启到已知好状态。
原则：不需要精确度量"偏差是多少"，只需要判断"是否偏差了"——这是一个二值判断。
具体手段：

异常检测：测试失败、类型错误、构建失败、超时——任何一个都算异常
kill + restart from checkpoint：检测到异常后杀掉当前执行，从最近的 checkpoint 恢复
checkpoint 自适应间距：进展顺利时拉大间距（减少存档开销），反复失败时缩小间距（减少回滚损失）

Scalability 特性：

交互：环境必须支持快速 checkpoint 和快速 restart（目标：2 秒内恢复）
空间：每个 agent 独立 kill/restart，不影响其他 agent——监督树的叶子节点行为
时间：checkpoint 是时间维度上的"存档点"，跑多久都能回到最近的好状态

第 2 层：I 策略调整（分钟-小时级）
来源：Kálmán 的积分控制——消除系统性偏差，不是修 bug 而是修策略。
原则：单次失败是噪声，反复失败是信号。I 层响应的是模式，不是事件。
具体手段：

漏桶计数器：每次异常 +1，每步正常 -0.1。超过阈值 M 时触发策略变更
策略变更工具箱：修改 prompt 模板、切换工具链、调整权限范围、拆分任务粒度
滑动窗口防饱和（anti-windup）：I 分量只计算最近 K 步的累积，不从头算起——防止 agent 因早期错误而后期过度保守
K 值随阶段缩小：后期对偏差更敏感

Scalability 特性：

交互：策略变更通过配置文件下发，agent 在下次重启时自动加载——利用 P 层的 restart 传播配置
空间：P 层本地化（每 agent 独立），I 层跨 agent 聚合——一个 agent 偶尔犯的错是噪声，50 个 agent 都犯同一类错说明问题在 prompt 模板或工具链层面
时间：滑动窗口大小 K 随阶段调整——早期探索取大值（容忍波动），后期收敛取小值（快速捕捉偏差）

第 3 层：D 预警（趋势驱动）
来源：Boyd 的 OODA Loop——不等误差超标，在误差加速时就提前介入。
原则：agent 不会突然崩溃——它会先慢下来。趋势比阈值更早预警。
具体手段：

CUSUM 变点检测：对传感器时间序列做在线变点检测，统计特性（均值或方差）发生跳变时触发
紧急通道使用频率追踪：如果 P 层和 I 层的触发频率在加速，这本身就是系统退化的高阶信号
提前升级：通知人类或触发结构重组，不等到 I 层计数器溢出

Scalability 特性：

交互：CUSUM 算法轻量（几行代码），嵌入传感器运行时，零额外成本
空间：全局趋势面板——聚合所有 agent 的 D 信号，用一张表纵览系统健康度
时间：变点检测天然适合长时间运行——它专门寻找"什么时候 agent 的状态发生了质变"

元层：约束监控
来源：Leveson 的 STAMP 理论——事故发生不是因为组件失败，而是因为控制结构的假设过时了。
原则：监控 harness 本身，而非 agent。最危险的盲区是 harness 的假设过时了而你不知道。
具体手段：

约束-任务匹配度检查：当前约束是否仍然适用于当前任务状态？agent 是否在合法地"撞墙"——请求它确实需要但没有权限的资源？
传感器自检（Chaos Monkey）：定期向系统注入已知异常，检查传感器是否能检测到
误报率追踪：过去 N 次警报中多少被忽略或覆写——高误报率 = 传感器标定有问题
可控性分析（定期）：在任务进度 25%/50%/75% 时，检查是否有重要目标维度在当前架构下不可控

Scalability 特性：

交互：元层运行频率低（定期检查点），不常驻，不占用 agent 的执行资源
空间：看门狗模式守护全局聚合器的存活性
时间：最危险的时刻是第 4-6 小时——初始约束可能已不合适但还没到全局审查时间，元层在此区间提高警觉


二、传感器体系：风险匹配的动态配置
核心原则：传感器精度应匹配失败后果。便宜的传感器永远开着，贵的传感器条件激活。
传感器分类

一级传感器（始终开启，成本极低）



传感器
测量对象
信号类型
来源



测试通过/失败
代码功能正确性
二值
环境反射弧


编译/类型检查
代码结构合法性
二值
环境反射弧


Lint/静态分析
已知反模式
计数
环境反射弧


重启次数计数器
agent 的挣扎程度
计数
P 层副产物


需求覆盖率
spec 条目被实现了几条
百分比
任务管理器


二级传感器（高风险时激活，成本中等）



传感器
测量对象
激活条件



步速（token/步、时间/步）
agent 的行为节奏变化
一级传感器出现异常


回退频率
agent 的不确定性程度
步速骤变时


工具调用模式
循环思维检测
同一工具重复调用时


diff 结构分析
变更范围和性质
涉及跨模块修改时


跨沙箱契约验证
接口一致性
多 agent 修改同一边界时


元级传感器（定期 + 关键节点）



传感器
测量对象
运行频率



约束-任务匹配度
harness 的假设是否过时
任务进度 25%/50%/75%


传感器自检
传感器是否仍在工作
定期（Chaos Monkey）


误报率
传感器标定是否偏移
持续追踪


传感器配置矩阵
按失败后果动态选择传感器精度：
               可逆              不可逆
         ┌──────────────┬──────────────┐
  本地   │ 一级（二值）  │ 二级（节奏） │
         │ kill/restart │ 降速+审查    │
         ├──────────────┼──────────────┤
  跨域   │ 二级（契约）  │ 元级+人类    │
         │ 契约验证      │ 审查         │
         └──────────────┴──────────────┘
传感器的工程实现原则

环境反射弧优先：测试/lint/type check 的结果不是"报告给监控系统"，而是直接注入 agent 的下一步输入——传感器和执行器是一体的，没有中间分析层
传感器是运行时内建属性：心跳、退出信号、资源计量——这些是进程运行时的自然产物，不是外挂组件
日志不是传感器：日志是原始数据流，必须经过特征提取才能变成传感器信号
从控制动作倒推传感器需求：harness 只有 5 个控制动作（继续/kill+restart/修改策略/拆分任务/升级人类），不需要度量超出这 5 个动作所需信息的维度

动作审查门（前置传感器）
在每个副作用动作执行前拦截审查：

读取型 → 放行
写入型 → 检查约束 + 查全局写锁注册表
不可逆型 → 严审（可能请求人类批准）

审查严格度随任务阶段调节：早期宽松（鼓励探索），后期收紧（保护交付物）。

三、跨层通信：三种机制组合
核心原则：不是所有跨层通信都需要同一种机制。匹配场景选择最简方案。
机制 A：结构耦合（相邻层常规通信）
适用场景：P→I、I→约束层、D→人类
实现方式：

P→I：共享计数器。P 层每次 kill+restart 时计数器 +1。I 层定期读计数器，超过阈值即行动。不需要消息、队列、TTL。
I→约束层：配置文件。I 层修改策略时写入配置文件。Agent 下次重启（被 P 层 kill 后一定会重启）自动加载新配置。配置变更通过重启传播。
D→人类：报告文件 + 系统通知。不需要实时通道。

特点：零延迟、零基础设施、天然持久化。
机制 B：事件总线（跨 agent 协调）
适用场景：全局态势感知、跨 agent 协调、I/D 信号的全局聚合
实现方式：

分区消息队列（按 agent ID 分区，防全局争用）
消息 TTL 分级：P 层 anomaly = 1 小时，I 层 threshold_breach = 6 小时，元层 meta_alert = 任务全程
监督树结构映射为消息订阅拓扑——消息先到直接父节点，必要时向上传递

技术选型：轻量即可——Redis Stream、内存队列、甚至 Unix 管道。关键是所有跨 agent 通信必须经过这条总线，禁止旁路。
机制 C：安全门控通道（能力变更的下行通信）
适用场景：任何扩大 agent 能力边界的下行变更
核心规则：收缩方向和扩张方向走不同通道。

收缩方向（杀进程、收紧权限、缩小约束范围）→ 快通道，最小验证。收缩不扩大 agent 能力，本质上安全。
扩张方向（增加权限、放宽约束、增加工具）→ 慢通道，完整验证：影响分析 → 一致性检查（含全局写锁注册表）→ 配置快照 → 执行/阻断

配置版本链：每次下行变更前快照当前配置，形成可回滚的版本链——就像 git 对代码做的事。
触发条件（何时跨层通信）
触发检查内嵌于传感器本身，不是独立组件：

阈值突破：传感器读数超过自适应阈值（μ + nσ，基于滑动窗口计算）→ 触发 P 层
持续偏离：漏桶计数器超过阈值 M → 触发 I 层
趋势突变：CUSUM 检测到统计特性跳变 → 触发 D 层


四、结构重组：三个层次、四种策略
不可变核心（架构不变量）
以下是 harness 的"宪法"——运行时的任何自动化过程都不可修改它们：

安全验证门的逻辑
跨层通信的消息协议格式
"每个 agent 必须被某个监督者监督"这一关系
人类升级通道的存在性
kill + restart 的能力
传感器的类型和安装位置

修改不变量 = 宪法修正案 = 需要人类审查 + 版本发布。
三个重组层次



层次
内容
频率
成本
机制



参数滑动
超时值、阈值、OODA 速度
每步
零
PID 回路的正常工作


配置切换
prompt 模板、工具链、权限集、传感器级别
每阶段（2-4 次/任务）
低
加载预定义 profile


拓扑重组
监督树结构、agent 分配、任务分解
极少（0-2 次/任务）
高
蓝绿部署 / 竞速 / 权重矩阵


配置模板（阶段 profile）
profiles:
  explore:                    # 探索阶段：理解需求、阅读代码
    checkpoint_interval: 30m
    sensor_level: basic       # 一级传感器
    ooda_speed: slow
    constraint_strictness: loose
    attention_weights: focused  # 主模块权重高，其他低

  implement:                  # 实现阶段：写代码、改配置
    checkpoint_interval: 10m
    sensor_level: standard    # 一级 + 按需二级
    ooda_speed: fast
    constraint_strictness: medium
    attention_weights: expanding  # 逐渐展开跨模块可见性

  integrate:                  # 集成阶段：跨模块组装、端到端测试
    checkpoint_interval: 3m
    sensor_level: full        # 全传感器
    ooda_speed: fastest
    constraint_strictness: strict
    attention_weights: cross_module  # 跨模块权重升高

  converge:                   # 收敛阶段：最终测试、文档、清理
    checkpoint_interval: 5m
    sensor_level: full
    ooda_speed: slow
    constraint_strictness: strictest
    attention_weights: global  # 全局均匀
拓扑重组的四种策略
按确定性和风险选择：
策略 1：权重矩阵调整（最常用）
把离散的"一个 agent 负责一个模块"转变为连续的注意力权重矩阵。"重组"变成"权重调节"，走 PID 回路。
         模块A  模块B  模块C  模块D
Agent 1:  0.9    0.1    0.0    0.0
Agent 2:  0.1    0.8    0.1    0.0
Agent 3:  0.0    0.1    0.7    0.2
Agent 4:  0.0    0.0    0.2    0.8
权重随任务演化平滑调整：前期聚焦（主对角线高），后期扩散（全局趋于均匀）。
策略 2：渐进式迁移（常规拓扑调整）
新旧监督树并行运行，agent 在到达 checkpoint 时逐个迁移到新树，验证通过后关闭旧树。不停机、可回滚。分批金丝雀：先迁移 10% 验证，再迁移其余。
策略 3：竞速探索（不确定最佳方案时）
同时启动多条执行路径（fork from checkpoint），各用不同策略，谁先达标就采纳谁。用资源换速度和确定性。竞速必须有严格时间预算——预算耗尽仍无结果则升级给人类。
策略 4：冻结迁移（不可逆的关键变更）
暂停 → 快照 → 规划 → 验证 → 迁移 → 恢复。最安全但成本最高。仅在涉及不可逆变更时使用。
重组决策流
目标维度持续不达标
     │
     ▼
可控性分析（架构 agent）
     │
     ├─ 手段存在且可用 → 调参数（L1/L2）
     ├─ 手段存在但不可用 → 拓扑重组（L3）
     │    ├─ 知道新拓扑 → 权重调整 或 渐进迁移
     │    ├─ 不知道新拓扑 → 竞速探索
     │    └─ 涉及不可逆 → 冻结迁移
     ├─ 手段不存在 → 升级给人类（增加能力）
     └─ 目标本身有问题 → L4 目标修正（人类决策）
重组冷却期：两次 L3 重组之间至少间隔任务总时间的 10%。频繁触发 L3 自动升级为 L4——因为频繁需要拓扑重组说明问题在目标定义上。

五、三维 Scalability 完整方案

交互 Scalability：环境设计
环境 = 约束工厂 + 误差信号工厂 + 进程运行时
环境必备的 7 个组件：



#
组件
功能
优先级



1
沙箱运行时
文件隔离 + 网络限制 + 权限控制
最高


2
环境反射弧
自动测试/lint/type check，结果直接注入 agent
最高


3
Checkpoint 存储
快速保存/恢复 agent 状态（目标 2 秒）
最高


4
动作审查门
统一 action gateway，所有工具调用必经
高


5
事件总线
轻量消息队列，跨 agent 通信
高


6
写锁注册表
共享资源的并发控制
高


7
人类审批接口
L4 目标修正的入口
中


设计原则排序：约束 > 快反馈 > 精确反馈
空间 Scalability：几百个 agent 并行
组织结构：监督树
              全局监督者
             ╱    │     ╲
        子树A   子树B   子树C    ...
        ╱  ╲    ╱  ╲    ╱  ╲
      a1   a2  a3   a4  a5   a6  ...

叶子节点 = 执行 agent
父节点 = 监督 agent（执行 P 层 kill/restart、聚合 I/D 信号）
子树可独立做 L3 重组，不影响其他子树

并行策略：

P 层本地化：每 agent 独立 kill/restart
I/D 层按子树聚合：子树监督者做本层决策
传感器分级配置：95% Watt 级 / 4% Kálmán 级 / 1% Leveson 级（按风险长尾分布）
写锁注册表防跨 agent 资源冲突
注意力权重矩阵控制可见性，连续可调

分工方式：

初始按模块/功能分（权重矩阵主对角线高）
困难点竞速探索（fork 多路，选优合并）
权重随集成阶段展开，后期趋于均匀

收敛方式：

跨沙箱契约验证器保全局接口一致性
集成阶段由专门的集成 agent 子树完成
全局收敛检查：所有子树的需求覆盖率之和 ≥ spec 要求

时间 Scalability：十几小时连续运行
阶段模型与参数联动：
时间 ──────────────────────────────────────────────────►
0%            25%            50%            75%       100%
│             │              │              │          │
▼             ▼              ▼              ▼          ▼
探索           实现            集成           收敛       交付

OODA 速度：    慢             快              极快       慢
传感器级别：   基础           标准            全开       全开
审查严格度：   松(多读少写)   中              紧         极紧
权重分布：     聚焦主模块     渐展开          跨模块     全局均匀
Checkpoint：   间距大         间距中          间距小     每步存档
I 窗口 K：     大(容忍波动)   中              小(敏感)   最小
防退化的 6 个机制：

I 分量滑动窗口：只看最近 K 步，K 随阶段缩小
二级传感器自适应基线：μ + nσ 基于滑动窗口动态计算，不被早期噪声污染
约束定期刷新：在 25%/50%/75% 进度时做可控性分析
配置版本链：每次变更前快照，支持任意时间点回滚
紧急通道使用频率追踪：频率上升 = 系统在退化
Checkpoint 自适应间距：顺利拉大，失败缩小


六、完整架构图
╔══════════════════════════════════════════════════════════════════════╗
║                 HARNESS ENGINEERING 架构                           ║
║                                                                    ║
║  外部输入：需求 spec / 验收标准 / 优先级（人类注入）               ║
║                          │                                         ║
║                          ▼                                         ║
║  ┌──────────────────────────────────────────────────────────────┐  ║
║  │  不可变核心                                                  │  ║
║  │  安全验证门 │ 消息协议 │ 监督关系 │ 人类通道 │ kill 能力     │  ║
║  └──────────────────────────────────────────────────────────────┘  ║
║                          │                                         ║
║  ┌───────────────────────┼──────────────────────────────────────┐  ║
║  │  元层                 │                                      │  ║
║  │  架构 agent · 可控性分析(定期) · 元传感器 · L4→人类审批     │  ║
║  │  配置版本链 · 拓扑重组决策                                   │  ║
║  └───────────┬───────────┼───────────▲──────────────────────────┘  ║
║    下行:约束重塑          │           上行:元信号(趋势/分布偏移)     ║
║    (安全验证门)           │           (漏桶计数器/CUSUM)           ║
║  ┌───────────▼───────────┼───────────┴──────────────────────────┐  ║
║  │  D 层    CUSUM变点检测 │ 紧急通道频率追踪 │ 提前升级/人类     │  ║
║  └───────────┬───────────┼───────────▲──────────────────────────┘  ║
║    下行:策略变更          │           上行:趋势加速度               ║
║    (收缩=快/扩张=慢)      │                                        ║
║  ┌───────────▼───────────┼───────────▲──────────────────────────┐  ║
║  │  I 层    漏桶计数器    │ 跨agent聚合 │ 修改prompt/工具/权限   │  ║
║  │          滑动窗口防饱和│                                      │  ║
║  └───────────┬───────────┼───────────▲──────────────────────────┘  ║
║    下行:配置文件          │           上行:重启计数(结构耦合)       ║
║    (重启时生效)           │                                        ║
║  ┌───────────▼───────────┼───────────▲──────────────────────────┐  ║
║  │  P 层    异常检测(二值)│ kill+restart from checkpoint         │  ║
║  │          checkpoint自适应间距                                 │  ║
║  └───────────┬───────────┼───────────▲──────────────────────────┘  ║
║              │           │           │                             ║
║  ┌───────────▼───────────┼───────────┴──────────────────────────┐  ║
║  │  约束层   沙箱 │ 权限白名单 │ 硬超时 │ 动作审查门            │  ║
║  │           注意力权重矩阵（可见性控制）                        │  ║
║  └───────────────────────┼──────────────────────────────────────┘  ║
║                          │                                         ║
║  ┌───────────────────────▼──────────────────────────────────────┐  ║
║  │  Agent 运行时                                                │  ║
║  │  · 环境反射弧(测试/lint/typecheck → 直接注入agent输入)       │  ║
║  │  · 内建传感器(心跳/退出信号/资源计量)                        │  ║
║  │  · 行为模式传感器(步速/回退频率/工具调用模式)                │  ║
║  │  · 每个副作用动作经动作审查门                                │  ║
║  └──────────────────────────────────────────────────────────────┘  ║
║                                                                    ║
║  跨 Agent 基础设施                                                 ║
║  ┌──────────────────────────────────────────────────────────────┐  ║
║  │  事件总线(分区消息队列) · 全局写锁注册表 · 监督树            │  ║
║  │  权重矩阵管理器 · 阶段profile管理器 · 配置版本链存储         │  ║
║  └──────────────────────────────────────────────────────────────┘  ║
╚══════════════════════════════════════════════════════════════════════╝

七、从概念到代号的映射表
给工程实现者的快速参考——把控制论术语映射到你已经熟悉的工程概念：



控制论概念
Harness 工程对应
你可能已经知道的类比



负反馈回路
测试失败 → 修代码 → 重测
CI/CD 红绿灯


设定值
需求 spec + 验收标准
User Story 的 AC


误差信号
测试失败数 + lint 错误数
PR Check 的红色项


P 控制
即时修复或 kill+restart
git revert + 重跑


I 控制
趋势分析 → 修改 prompt/工具
Sprint 回顾 → 改流程


D 控制
变点检测 → 提前预警
监控告警的 anomaly detection


物理约束
沙箱 + 权限 + 超时
Docker 容器 + RBAC


必要多样性
控制手段的丰富度 ≥ 故障模式的多样性
Runbook 覆盖率


信道容量
harness 的信息处理预算
团队的 On-call 带宽


超稳定系统
快回路失败 → 慢回路重构快回路
"如果重试不行就换方案"


可观测性
传感器能否重构 agent 的真实状态
OpenTelemetry 的 trace


飞球调速器
环境反射弧——输出直接耦合到输入
编辑器的实时红色波浪线


Let it crash
崩溃没关系，重启要快
Kubernetes Pod 重启策略


监督树
父进程管理子进程的层级结构
K8s Deployment → ReplicaSet → Pod


蓝绿部署
新旧拓扑并行运行，验证后切换
蓝绿部署本身


OODA Loop
观察-判断-决策-行动的循环速度
热部署的 feedback loop


STAMP/STPA
安全约束分析——哪些控制动作在哪些上下文下是不安全的
Threat Modeling


注意力权重矩阵
agent 对各模块的可见性权重
文件系统挂载点



八、开放问题

权重矩阵的自动调节：权重怎么自动调？启发式规则（失败多就降权、协作多就升权）可能足够启动；后期可演化为在线学习。

架构 agent 的设计：这个 agent 不执行任务，只观察拓扑健康度。它的传感器是失配度 R 和可控性分析。它本身也需要被监督——但它的监督者是人类。

人类介入频率：最低频率 = 任务进度 25%/50%/75% 的三次检查点。额外介入 = D 层升级或 L4 目标修正提案时。目标：人类每天介入不超过 5 次。

Checkpoint 的内容：最小可行 checkpoint = 已完成工作的文件快照 + 当前任务分解状态 + 最近 K 步的传感器摘要。不需要保存 agent 的完整上下文窗口——从 checkpoint 恢复时重新构建上下文。

契约的自动生成与验证：当 agent 修改一个模块的接口时，自动从代码中提取接口签名作为契约。其他依赖该接口的 agent 在执行前自动检查契约是否兼容。技术上可以用类型系统实现。



      

      看完了？说点什么呢
      
    ]]>
    
  69d5f072aeed68b915a3c8be
  posts
cn
 
  
    
    https://dhpie.com/posts/en/harness-and-agentic-engineering-controlling-a-system-that-makes-its-own-decisions
    Mon, 06 Apr 2026 15:14:46 GMT
    cover

An Unplanned Loss of Control

The first two
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/en/harness-and-agentic-engineering-controlling-a-system-that-makes-its-own-decisions
      

An Unplanned Loss of Control
The first two pieces covered how AI "sees" (Prompt and Context Engineering) and how it "acts" (MCP and Skills). By that point the puzzle looked nearly complete: feed the model information, it reasons, it executes through tools. Then something happened on a real project that showed me a critical piece was still missing.
I was using Claude Code to refactor an API layer — migrating old endpoints to a new routing structure. Clear Context, relevant Skills loaded, MCP connected to the codebase and docs. It started working. The first several steps went smoothly: identifying old routes, creating new files, migrating logic. Then it made a judgment call on its own. It decided certain old test files were "no longer needed" and deleted six test cases.
The reasoning wasn't absurd. Those tests were indeed written for the old routes. But what the model didn't know was that three of them covered edge-case regression scenarios. Deleting them left our CI pipeline exposed.
Where was the fault? Not the model's capability. Not the Prompt. Not the Context. Not MCP or Skills. The fault was that nobody had defined: who decides the model is allowed to delete files? Who sets the boundary for "stop and ask me at this point"? Who manages the rhythm and limits of this loop?
That's what a Harness is for.
Harness: Not Another Framework — A Different Kind of Framework
The word "harness" literally refers to the gear you put on a horse so the rider can control direction and speed. In AI engineering, it refers to the application layer wrapped around the model.
Let me first clarify what it's not. It's not a tool library like LangChain. It's not a technique like RAG. It's not a specific product. Harness is an architectural role. The analogy is its position in an AI application is what Spring Boot is to a Java web app, or what Next.js is to a frontend app.
Take Claude Code as an example. Its Harness runs through this sequence on every turn: on startup, load CLAUDE.md, Memory, MCP configurations, and the Skill catalog. When your message arrives, assemble all of that with your input into a complete API request and send it to the model. When the model responds, parse the output — if it contains tool calls, execute them. Feed the results back to the model and start the next turn.
Drawn out, it's a loop:

What role does the model play in this loop? It's one link in the chain, not the whole chain. This matters. The same Claude model, on the claude.ai web interface, can only chat. Inside Claude Code, it can read and write files, execute commands, call MCP servers. The model didn't change. The Harness changed.
During our roundtable, my colleague Xiaolin offered an analogy that stuck with me: a Harness is the management system of a restaurant. It determines what uniform the servers wear (System Prompt), where the training manual is kept (Skills), which outside lines they can call (MCP), and where customer records are stored (Memory). The same server working at two different restaurants can perform completely differently because the management systems are different.
Closed Loop: A Principle Figured Out in 1948
Here's an insight that took me a while to fully appreciate.
Traditional application frameworks pursue maximum control. When you build a web app, you define every route handler, every middleware chain, every request flow. System behavior is deterministic. Deviations come from bugs. Eliminate bugs, eliminate deviations.
A Harness faces a different situation. The core component it wraps — the language model — is inherently non-deterministic. You can't eliminate deviation. You can only manage it. This creates a fundamental divergence in design philosophy: traditional frameworks maximize control; a Harness maximizes autonomy while maintaining reliability.
This sounds like a freshly minted theory, but it isn't. In 1948, mathematician Norbert Wiener published a book called Cybernetics, subtitled "Control and Communication in the Animal and the Machine." The core problem he defined was: effective governance of systems that exhibit autonomous behavior. The methodology: closed-loop feedback control — set a goal, act, observe the result, compute the deviation, adjust, act again.
Traditional frameworks are open-loop: you issue an instruction, the program executes, done. A Harness is closed-loop: after the model produces output, the Harness observes the result (any tool calls? are they reasonable?), decides the next move (execute the tool? or pause and ask the user?), then feeds the result back to the model to continue the loop.
The problem Wiener defined 78 years ago and the problem AI Harnesses solve today are structurally the same.
Three Levels of Engagement
Understanding what a Harness is, in practice you'll find yourself at one of three levels.
Level one: use an off-the-shelf Harness. ChatGPT, Claude.ai, Gemini — these are Harnesses someone else built. You just type. The vast majority of people are here, and that's perfectly fine.
Level two: configure an existing Harness. This is where the effort-to-impact ratio peaks. With Claude Code, for instance, you can: write a CLAUDE.md that tells AI your project context and work standards; configure Memory for cross-session continuity; connect MCP Servers for external service access; install Skills for standardized procedures; set up hooks that trigger custom logic before or after specific operations (e.g., "run tests automatically before every commit"). Stack these configurations together and you're tuning the Harness's behavior.
Level three: build a Harness from scratch. This means handling model API calls, tool execution, context management, error recovery, and concurrency control yourself. Most teams never need to go here, but knowing it exists helps you see the full picture.
Back to my deleted-tests incident. The fix wasn't a better Prompt or different model parameters. It was a hook at the Harness level: when AI attempts to delete a file, prompt for confirmation. Five minutes to set up. Never happened again.
Agentic Engineering: Where to Draw the Trust Boundary
At this point, the Harness picture is clear. But there's a question one level above it.
Harness answers how — how do you control an autonomous system. But before the how, there's a why that needs answering first: how autonomous do you actually want this system to be?
That's what Agentic Engineering addresses. Its relationship with Harness isn't sequential — they sit on different axes. Agentic is design at the goal and philosophy level. Harness is engineering at the implementation level. You first decide "how autonomous a system am I building," then design "how to control it."
An Agent can be defined as the combination of Prompt + Context + MCP + Skill + Harness. The previous articles covered the components. Harness is the orchestration. Together, they constitute an Agent. But what Agentic Engineering actually grapples with are the emergent problems that appear after combination.
Autonomy boundaries. How much freedom does the AI get? Can it modify code on its own? Delete files? Spend money on paid APIs? Send messages on your behalf? Traditional systems handle this with RBAC — roles and permissions hardcoded in configuration. But an Agent's decisions are dynamic and semantic. It's not "called an unauthorized API." It's "made a judgment that looked reasonable but shouldn't have been made."
Error accumulation. In a 10-step task, if step 3 drifts, the remaining 7 steps are built on a flawed foundation. Traditional distributed systems address this with the Saga pattern: every step has a compensating action, so you can roll back. But an Agent's errors are semantic. It refactored a piece of code "wrong" — how do you precisely roll back a judgment?
Multi-Agent coordination. One Agent writes code, another reviews it, a third runs tests. How do they work together? Traditional microservices coordinate through explicitly defined API contracts. But Agents communicate in natural language — ambiguous, context-dependent, blurry at the edges.
Human-AI trust. The problem that gives me the most trouble. An Agent completes a complex task. How do you verify the result? If you check every step, you might as well have done it yourself. If you don't check, who bears the risk? Traditional approval workflows are binary — approve or reject. But an Agent's output requires semantic comprehension to evaluate.
These four classes of problems share a single root cause: non-determinism and semantic ambiguity. Every methodology in traditional software engineering — testing, type systems, permission models, transaction mechanisms — is built on a foundation of determinism. Agentic Engineering operates on ground that is inherently fuzzy.



Agentic Problem
Traditional Counterpart
What's New



Autonomy boundaries
RBAC permissions
Traditional permissions are static; Agent decisions are dynamic and semantic


Error accumulation
Saga pattern
Traditional errors are rollbackable; Agent errors can't be precisely reversed


Multi-Agent coordination
Microservices / Actor model
Traditional interfaces are explicit; Agent communication is natural language, ambiguous


Human-AI trust
Approval workflows
Traditional review is binary; Agent review requires understanding semantic context


Six Concepts, One Map
Three articles, six concepts. Here's how they fit together.

Read bottom-up: a Prompt is one thing you say. Context Engineering determines what AI has already seen before you speak. MCP connects AI to the outside world. Skills tell AI what to do when it encounters a specific task. A Harness orchestrates all of this into a running closed-loop system. Agentic Engineering sits at the top, posing a values question: how autonomous should this system be?
Top-down works too: first answer "how autonomous a system do I want" (Agentic), then design "how to control it" (Harness), then choose "which components to use" (Context + MCP + Skill), and finally get specific about "what to say at each step" (Prompt).
Both directions are valid. In practice, most people work bottom-up, climbing the layers only when they hit a problem. That's fine. What matters is knowing the upper layers exist, so you don't spend hours grinding at the Prompt level on a problem that belongs at the Harness level.
A Simple Workflow
Before wrapping up, a concrete example that threads the concepts together.
Say you want to build an Agent for daily code review. Walking up from the base:

Prompt layer: The user says "review today's PRs."
Context layer: The Harness automatically injects project coding standards (CLAUDE.md), yesterday's review notes (Memory), and the current PR diffs.
MCP layer: Pull the PR list and code changes through a GitHub MCP Server.
Skill layer: Load the team-code-review Skill, which defines inspection rules and output format.
Harness layer: Orchestrate the loop — pull the PR list, run the review Skill on each PR, aggregate results, pause and notify a human if critical issues are found.
Agentic layer: Design decisions — should review results be posted as PR comments directly, or sent to a person first? If a security vulnerability is found, can the Agent block the PR on its own? These trust boundaries need to be set in advance.

You don't redesign all six layers from scratch each time. Most of the time you're using someone else's Harness, configuring your own Context and Skills, and occasionally confronting an Agentic-level design choice. But when the system doesn't behave as expected, knowing which layer the problem might live in makes debugging dramatically faster.
Closing the Series
Three articles, six concepts, one week of writing. The thing that strikes me most at the end: AI engineering practice is moving very quickly from craft to system.
Six months ago, knowing how to write a Prompt counted as "knowing how to use AI." Today, Prompt is the atomic layer, and there are four layers above it. This architecture is still evolving fast. The four-layer diagram I've drawn today might need revision in six months. But the underlying problem structure is unlikely to change: how do you collaborate with a non-deterministic system, and how do you find the balance between autonomy and control.
Wiener was already thinking about this in 1948. In 2026, we've encountered it again in a different form.
If you've read this far and haven't gotten your hands dirty yet, start at level two: pick an AI tool you use often and spend thirty minutes configuring its Harness. Write a CLAUDE.md. Install an MCP Server. Create a Skill. You'll find that adjusting AI's working environment delivers results far faster than adjusting what you say to it.
Then pay attention: how many decisions are you willing to let it make on its own? At what point do you start feeling uneasy? That point of unease is where your Agentic Engineering practice begins.

      

      看完了？说点什么呢
      
    ]]>
    
  69d3cde6ad24840827be6cd9
  posts
en
 
  
    
    https://dhpie.com/posts/en/mcp-and-skills-giving-ai-hands-feet-and-a-playbook
    Mon, 06 Apr 2026 15:14:45 GMT
    cover

A Very Specific Frustration

In the previou
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/en/mcp-and-skills-giving-ai-hands-feet-and-a-playbook
      

A Very Specific Frustration
In the previous piece, I covered Prompt and Context Engineering, which boils down to one question: how do you get the right information in front of AI? But seeing information and acting on it are completely different things.
Here's something that happened to me recently. I asked AI to check my calendar for next week, find scheduling conflicts, and email the summary to a colleague. Three simple tasks. It couldn't do any of them. No access to Google Calendar, no ability to check real-time data, no way to send email. It was like a consultant locked inside a soundproof glass booth: brilliant hearing, razor-sharp analysis, but no hands and no eyes.
This isn't a cognitive limitation. It's a physical one. AI has three innate blind spots: its knowledge has a cutoff date, it can't execute actions, and it can't access private data. You can craft the perfect Prompt, set up the most thorough Context, and those three walls are still there.
The two concepts I want to unpack here address different layers of this problem. MCP handles "letting AI reach the outside world." Skills handle "making sure AI does the job right."
MCP: USB for the AI World
Cast your mind back to computers around the year 2000. Keyboards used PS/2 ports, printers used parallel ports, mice used serial ports, scanners used SCSI. A different connector for every device. Then USB arrived and one port handled everything.
MCP, the Model Context Protocol, does essentially what USB did: it defines a standard protocol so AI applications can connect to external services in a uniform way.
Without MCP, if you want AI to read your Google Calendar, you write custom integration code: authentication flow, API calls, response parsing. Want to add GitHub? Write another integration. Gmail? Another one. N AI apps talking to M services means N times M integrations. Anyone who's done enterprise systems integration knows this pain.
With MCP, Gmail provides a single MCP Server, and any MCP-compatible AI client plugs right in. N times M collapses to N plus M.

Engineers will recognize the pattern. MCP is essentially an RPC specification where the caller happens to be a language model instead of a program. If you've used ODBC or JDBC, the mental model transfers almost directly: the application doesn't need to know the database's specific dialect because the middleware translates.
The protocol defines three primitives: Tools (actions AI can perform, like "send an email"), Resources (data sources AI can read, like "recent meeting notes"), and Prompts (predefined interaction templates). Communication runs over JSON-RPC, so there's no learning curve for anyone with web development experience.
During our roundtable discussion, my colleague Xiaolin offered an analogy I thought was spot on: MCP is like a unified system for restaurant servers. Before, checking kitchen inventory meant calling the back line, looking up a customer's loyalty status meant flipping through a binder, and ordering delivery meant opening a separate app. Now one system, one interface, handles it all.
A Bucket of Cold Water
The technical design of MCP is elegant, but whether a standard actually unifies anything has never been about the technology itself.
USB succeeded because Intel, Microsoft, and Apple all lined up behind it. If Intel had pushed USB while Microsoft pushed FireWire and Apple went its own way, your desk might still be a tangle of different cables today. MCP has momentum. Anthropic led the initiative and other AI companies are following. But the ecosystem politics are far from settled.
There's a security dimension too. MCP gives AI the ability to perform real actions: send emails, modify files, execute code. If a prompt injection attack triggers a Tool through MCP, the consequence isn't just a wrong answer. It could be an email that should never have been sent. Greater capability means a larger attack surface. That's not a problem technology solves on its own.
Skills: A Standard Operating Procedures Manual for AI
AI now has hands and feet. But having hands and feet doesn't mean knowing how to work.
In the operations world, there's a document called a Runbook: when a service goes down, step one is check this, step two is restart that, step three is notify this person. Every step has preconditions and verification checkpoints. A Runbook doesn't teach you ops fundamentals. It assumes you already have the baseline capability and locks down "the correct way to handle this specific situation."
A Skill does the same thing, except the reader is AI instead of a human engineer.
A concrete example. I have a recurring task: publish a Markdown article to a WeChat Official Account. This involves converting Markdown to HTML, uploading images to a CDN and rewriting links, calling the WeChat API to create a draft, and dealing with various formatting compatibility issues. Spelling all that out in a Prompt every single time is both inefficient and error-prone. Details I remembered last time might slip through the cracks this time.
Package those steps into a Skill, and AI automatically loads it whenever it encounters this type of task. The Skill specifies: the trigger condition ("when the user asks to publish a WeChat article"), the steps involved, which tools to use, constraint rules ("images must be uploaded to R2 before links are rewritten"), and representative examples.
The relationship between Skills and Prompts fits on a single axis:

A Prompt is a one-time instruction that disappears after the conversation. A Skill is persistent, version-controlled, and shareable. Fix a bug by adding a rule to the Skill, and everyone using it benefits. This mirrors the logic of a software library: a packaged unit of capability that you import when needed.
But a Skill isn't quite a code library either. It's closer to a Runbook plus Configuration. The Runbook defines the procedure. Configuration defines parameters and constraints. A Skill contains both.
Here's the key insight: a Skill doesn't teach AI new abilities. AI already "sort of knows" how to do most things. Ask it to convert Markdown to HTML, it can. Ask it to call an API, it can. What a Skill solves is turning "sort of knows" into "reliably gets it right." The difference lives in the details. WeChat's HTML renderer doesn't support certain CSS properties, image links must use HTTPS, code blocks in the body need special treatment. AI won't know these things spontaneously, but once they're written into a Skill, it gets them right every time.
A formula: Skill = general capability x specific constraints x repeatable execution.
Getting Your Hands Dirty
Enough concepts. Here's what it looks like in practice.
Installing an MCP Server, using Claude Code as an example. Suppose you want AI to query up-to-date technical documentation, say a framework's latest API. You add a context7 MCP Server in your project's .mcp.json:
{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@anthropic/plugin-context7"]
    }
  }
}
Once configured, when you say "look up how Server Actions work in Next.js 15," the AI fetches the latest docs through the MCP Server rather than relying on potentially stale training data.
Writing a simple Skill is equally straightforward. Suppose your team frequently asks AI to do code reviews, and you have specific standards. Create a Skill file:
---
name: team-code-review
trigger: When the user requests a code review
---

## Steps

1. Check for uncommitted changes and list modified files
2. For each changed file, check:
   - No function exceeds 50 lines
   - All public functions have docstrings
   - No use of `any` type (TypeScript projects)
   - No empty catch blocks
3. Summarize issues, sorted by severity
4. Provide specific fix suggestions for each issue

## Constraints

- Only inspect files changed in this diff, not the entire project
- Separate style issues from logic issues
- If nothing is found, explicitly state "No issues found in this review"
That's a minimal Skill. It's short, but it pins down the steps and standards for a code review. Next time anyone on the team triggers it, AI follows the same criteria.
What I Haven't Figured Out
MCP and Skills solve problems at two different layers, but new questions are already surfacing.
MCP keeps expanding what AI can reach. Skills keep tightening how AI should act. Stack these two together and AI autonomy becomes a real design decision: how wide an action radius do you grant it? Which operations require human confirmation, and which can run automatically? This is no longer a technical choice. It's a question of trust architecture.
I'm also uncertain about Skill granularity. Write it too coarsely and AI still stumbles on details. Write it too finely and maintenance costs climb, and you might actually be constraining AI from doing something better than your script anticipated. "Specific beats generic" feels like the right principle from my experience so far, but I haven't found the optimum.
In the first piece I left an open question: can AI decide for itself what information it needs to see? I can extend that now. When AI can independently fetch information through MCP and follow standardized procedures via Skills, does it already have the prerequisites for autonomous task completion?
That's exactly what the next piece will cover: Agents. An AI that can perceive, decide, and act is a fundamentally different creature from one that only answers questions. But before we get to Agents, MCP and Skills need to be understood first. They are an Agent's infrastructure. An Agent without hands is empty talk. An Agent without a playbook is a liability.
Pick the most repetitive AI task in your workflow and write a Skill for it. It doesn't have to be perfect. Just get it running. That's the fastest way into this whole system.

      

      看完了？说点什么呢
      
    ]]>
    
  69d3cde5ad24840827be6cc8
  posts
en
 
  
    
    https://dhpie.com/posts/en/prompt-and-context-engineering-what-you-say-and-the-room-ai-walks-into
    Mon, 06 Apr 2026 15:14:44 GMT
    cover

The question everyone keeps asking wrong

O
    该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://dhpie.com/posts/en/prompt-and-context-engineering-what-you-say-and-the-room-ai-walks-into
      

The question everyone keeps asking wrong
Over the past six months, I've been asked some version of the same question dozens of times: "How do I write a better prompt?" Product managers, founders, friends who run newsletters, even my mother. I always tried to give a thoughtful answer, but something never sat right. Eventually I figured out the problem: the question itself is too narrow. It's like asking "what should I say to the waiter to get a good meal?" You can teach someone better ordering technique, but what actually determines dinner quality is which restaurant they walked into.
This is the first in a series where I want to unpack a handful of new concepts that kept coming up in my AI engineering work over the past year. Not a glossary, but a walk through actual usage scenarios — why these concepts got invented, and how they relate to each other.
Today: the two most foundational ones. Prompt, and Context Engineering.
Prompt: a very unusual kind of talking
The word "prompt" sounds unremarkable. But it conceals something genuinely novel: this may be the first time in the history of software engineering that an API's input and output are both non-deterministic.
In traditional programming, a SQL query with the same input produces the same output. A function with the same arguments returns the same result. Prompts don't work this way. Ask ChatGPT to "write me an email" and you'll get something different every time. More subtly, a small change in phrasing — adding "use a formal tone" — can completely alter the result.
So what is a prompt, really? It's an API call written in natural language. Technically, it's the messages field inside an HTTP request body. In that sense it's no different from a SQL statement sent to a database. But in practice, it feels exactly like a conversation between two people.

This duality is precisely why the concept needed its own name.
I used to compare prompting to ordering food: the clearer you are, the more likely you'll get what you want. That analogy works for beginners, but it hides something important. Ordering only requires knowing what you want. Writing a good prompt often requires doing four things simultaneously: assigning a role ("you are a senior editor"), describing a task ("revise this paragraph"), setting constraints ("keep the original tone, under 500 words"), and providing examples ("something in this style").
Role, task, constraints, examples. Together, these form an engineering discipline. That's why "Prompt Engineering" became a field of its own, rather than just "learning to talk to AI."
The turning point: good prompts aren't enough
Up to this point, it might sound like mastering prompts is all you need. I thought so too, for a while.
The turning point came when I started using Claude Code on real projects. I once crafted an extremely detailed prompt — clear requirements, reference examples, explicit constraints. The output was still mediocre. After a long debugging session, I found the issue: the model was missing the project's tech stack, didn't know our framework, had no sense of existing code style, and was completely blind to the business context.
My prompt was fine. The problem was that the AI had seen too little before it started answering.
Think of it this way. You walk into a fine French restaurant and tell the waiter: "Your best steak, medium-well, with a red wine pairing." Clear, specific, even sophisticated. But if this waiter is on their first day, doesn't know what the kitchen has in stock, hasn't seen the wine list, and doesn't know you had an allergic reaction to shellfish last time — your eloquence won't save the meal.
What determines service quality isn't just what you say. It's how much the waiter already knows before you open your mouth.
Context Engineering: furnishing the room AI walks into
This brings us to the second concept: Context Engineering.
If a prompt is "what you say to AI," then context is "the room AI walks into." Context Engineering is the discipline of furnishing that room before AI starts working.
Staying with the restaurant analogy: before you say a word, a well-run restaurant has already done extensive prep. The type of restaurant determines the base menu (that's the System Prompt). Your membership profile records your preferences and allergies (that's Memory). Today's inventory and specials have been synced to the waiter (that's retrieved documents). Whether you're in a private room for a business dinner or at a family table — the waiter is aware of that scene (that's session state).
For the technically inclined, the mapping is clean:



Software engineering concept
AI equivalent



Global config / env variables
System Prompt / CLAUDE.md


Session state
Conversation history / Memory


Request payload / HTTP body
User's Prompt


Dependency injection / libraries
Retrieved documents and code



The shift from Prompt Engineering to Context Engineering moves the central question: from "how do I say this clearly" to "what should AI see, and in what order."
This looks like a simple expansion of scope. It's actually a qualitative change. Language models have finite context windows. Even the most advanced models today handle a few hundred thousand tokens. Faced with all the code and documentation of a real project, if it doesn't fit, it doesn't fit. You have to make choices: what goes in, what gets cut, and how you order what remains.
This reminded me of search engines. Google's problem is: billions of web pages exist, a user types a query, you can only return the top ten results — how do you choose which ten? Context Engineering faces a structurally identical problem: millions of tokens of potentially relevant information, but a window of only a few hundred thousand. What makes the cut?
What you can do today
On the practical side, there are things you can improve at both levels right now.
At the prompt level, keep the four elements in mind: role, task, constraints, examples. You don't need all four every time, but having the framework helps. Often when AI underperforms, it's not because the model is inadequate — it's because you forgot to specify what role it should play or what boundaries to respect.
At the context level, pay attention to the capabilities your tools already offer. Claude Code's CLAUDE.md file is a textbook System Prompt entry point — you can write your project's tech stack, code conventions, and business rules there, and the AI reads it on every startup. Memory features in various AI assistants are essentially long-term context maintenance. RAG (Retrieval-Augmented Generation) dynamically injects relevant documents into each conversation.
The logic behind all these tools is the same: they help you furnish the room AI is about to walk into.
An unresolved question
One thing I haven't figured out yet.
The core challenge of Context Engineering is information triage. But triage requires judgment, and judgment itself — can that be delegated to AI too? In other words, letting AI decide what it needs to see. If you follow that thread to its conclusion, does the boundary between Prompt and Context dissolve entirely?
I'll save that question for later in the series. The next piece covers Agents and Agentic Workflows, and by then, "who decides what AI sees" becomes an even more pressing question.

      

      看完了？说点什么呢
      
    ]]>
    
  69d3cde4ad24840827be6cb7
  posts
en