过去一年，Context Engineering 这个词越来越火。大家都在讨论怎么设计 prompt，怎么组织检索结果，怎么压缩上下文，怎么让模型在有限 context window 里做出更好的回答。
这件事当然重要，而且它确实解释了很多现象。为什么同一个模型，在不同系统里表现会差这么多？很大程度上，就是因为喂给它的 context 完全不同。谁更会组织 instructions、examples、history、retrieval context、tool schema，谁就更容易拿到更稳定的输出。
但如果你真的开始长期使用一个 AI 助手，很快会遇到另一层问题。
你会发现，单次回答质量当然重要，但更重要的是：它下次还记不记得你？它会不会积累经验？它能不能把一次做对的事情，变成下一次更自然的默认动作？它会不会随着合作变久，慢慢长出一种“越来越懂你”的工作方式？
这时候，你会意识到一个事实：真正重要的，已经不只是 Context，而是 Harness。
Context Engineering 解决的是“这一轮怎么喂”
我并不想贬低 Context Engineering。恰恰相反，我觉得它是过去两年里非常重要的一次认知升级。
因为在 Prompt Engineering 时代，很多人还把问题理解成“怎么把一句提示词写得更聪明”。到了 Context Engineering，大家开始意识到，模型的表现并不是由一句 prompt 决定的，而是由整个上下文系统共同决定的：系统指令、示例、历史对话、检索内容、工具定义、文件内容、状态信息、压缩策略，这些东西加在一起，才构成了模型眼中的现实。
OpenAI 在官方文档里就把 retrieval-augmented generation 归到这种思路之下：把额外相关信息加入当前生成请求，以便模型在本轮回答里拥有更好的依据。Anthropic 在讲 agent 的文章时，也一再强调 tool design 和 agent-computer interface 的重要性。它们说的其实都是同一件事：模型不是凭空变好，而是在被更好地喂养。
所以 Context Engineering 的核心问题其实很清楚：在当前这一轮任务里，到底该给模型看什么，怎么给，给多少，按什么顺序给。
这是一层非常关键的工程，而且今天依然成立。没有它，很多系统连第一步都走不稳。
但个人 AI 助手真正缺的，往往不是更多上下文
问题是，当你把 AI 从“回答一个问题”升级成“长期和你一起工作”的个人助手时，Context Engineering 很快就会显得不够。
因为上下文再长，也只是这一轮的。你今天把所有背景都喂进去，明天还得重新喂一遍。你这次手把手带它完成一个复杂任务，下次它还是有可能从头再来。你可以不断复制粘贴自己的偏好、流程、口径、要求，但这件事本身就说明：系统并没有真正把这些东西变成自己的能力。
一个真正好用的个人 AI 助手，不应该永远停留在“每次都要重新对齐”的状态。它应该在长期合作里，慢慢形成自己的工作惯性。它知道你更喜欢怎样的交付格式，知道什么信息值得长期记住，知道哪些事情需要先做完再来打扰你，知道哪些流程可以直接调用，哪些场景必须让你确认。
这些能力，并不是靠把 context window 再拉长一点就能自动长出来的。
它需要别的东西。需要记忆，需要技能，需要运行时的约束，需要反馈回路，更需要一种能不断修正自己的机制。换句话说，它需要一个 Harness。
什么叫 Harness
我越来越倾向于把 Harness 理解成：模型之外，让它能长期工作的那整套支架。
这里面至少包括几层东西。
第一层是 Memory。不是把聊天记录原封不动堆起来，而是有层次地保留工作记忆、日志记忆、长期记忆、反思记忆。它不只是记住发生过什么，更重要的是，能从发生过的事情里抽出规律，形成下一次更好的默认行为。
第二层是 Skill。Skill 不是一个花哨的 prompt 模板，而是一个可复用的工作单元。它知道自己在什么时候该被触发，什么时候不该被触发；它可能附带脚本、资源、参考文档，甚至验收标准。它的作用不是“多教模型一点知识”，而是把某类任务沉淀成一种稳定能力。
第三层是 Tool 和 Runtime。也就是模型调用外部世界的方式：文件、终端、浏览器、MCP、搜索、数据库、API、审批边界。这些东西决定了它能不能真正行动，而不是停留在“会说”。
第四层是 Evaluation 和 Guardrails。一个长期运行的系统，不可能只靠运气变好。它需要知道自己哪里做对了，哪里做错了，什么时候偏了，什么时候越界了。否则所谓“自我进化”很容易变成“自我漂移”。
把这些东西放在一起，你就会发现，Harness 关心的已经不是“这轮输入怎么组织”，而是这个 agent 在长期协作里，会不会逐渐形成稳定能力。
这就是为什么我觉得，新时代真正重要的是 Harness Engineering
如果说 Context Engineering 关心的是“本轮输入编排”，那 Harness Engineering 关心的就是“长期运行支架”。
它们不是互相替代的关系，更像层级不同的关系。Context 是 Harness 的一部分，但不是全部。你当然还得解决这一轮怎么喂，可你也必须开始解决：喂过一次以后，系统会留下些什么；做对一次以后，它能不能变得更会做；做错一次以后，它能不能少犯同样的错。
这就是我为什么觉得，个人 AI 助手时代最关键的变化，不是 context engineering 消失了，而是它被放进了一个更大的框架里。真正决定上限的，不再只是“上下文组织得好不好”，而是“有没有一个能让 agent 长期学习和稳定协作的 Harness”。
你也可以把它理解成：Context Engineering 解决的是短程表现，Harness Engineering 解决的是长期人格。
个人 Harness 里，最重要的其实是 Memory 和 Skill 会不会进化
我现在对个人 AI 助手最强烈的一个判断是：未来谁更像“你的搭档”，不取决于它记住了多少，而取决于它会不会更新自己的记忆，以及会不会演化自己的技能。
因为记忆最大的风险，从来不是不够多，而是太多。什么都记，很快就会变成噪音池。今天一句随口偏好，明天一个临时任务，后天一次并不稳定的表达习惯，如果全都被无差别地塞进长期记忆，系统很快就会被自己的历史拖垮。
所以一个好的 Memory 机制，首先不是“尽量多存”，而是“知道什么该留下，什么该忘掉”。更进一步，它还要会修订。用户今天说过的话，未来可能改变；系统之前归纳出的偏好，后面可能被新的行为推翻。长期记忆如果只增不改，最后一定会越来越像一份过期档案，而不是活的工作模型。
Skill 也是一样。很多系统一开始都很热衷于沉淀 skill，结果沉淀着沉淀着，就把自己沉淀成了一座废墟。skill 越来越多，触发边界越来越模糊，说明越来越重叠，最后要么误触发，要么谁也不触发。
所以 skill 真正需要的，不只是 creation，更是 evolution。它要能被拆分、改写、弱化、归档、淘汰。一个 skill 长期没人用，就应该进入归档候选；一个 skill 覆盖范围越来越宽，就应该拆成两个更聚焦的 skill；一个 skill 误触发率太高，就应该重写 description，而不是继续堆补丁。
从这个角度看，真正决定个人 Harness 质量的，不是 memory 和 skill 有没有，而是它们是不是活的。
“自我进化”不是玄学，而是一套更新机制
很多人一说到 AI 的自我进化，就容易往很玄的方向想，好像系统会自己长脑子一样。其实我越来越觉得，这件事没有那么神秘。所谓自我进化，真正落到工程上，无非就是三件事：记录、反思、更新。
先是记录。系统得知道发生过什么：做了哪些任务，哪些地方返工了，哪些输出被用户明确认可，哪些地方总是出错。这是最基础的一层，没有它，后面所有“变好”都无从谈起。
然后是反思。不是把日志原样留在那里，而是从里面找出那些会反复出现的模式。什么偏好是稳定的，什么需求只是一次性的，什么错误是偶发，什么错误是结构性的，什么成功动作已经值得提炼成默认套路。
最后才是更新。把真正有价值的部分写回长期记忆，把成熟的流程升级为 skill，把失效的规则降级或删掉。这里最关键的一点是：更新不能全自动乱改。数据可以自动记录，规则可以自动起草，但真正会改变长期偏好、工作边界和系统身份的东西，最好还是有人把关。
所以我心里理想的个人 Harness，并不是一个每时每刻都在偷偷重写自己的人，而是一个有节奏、有分层、有审计的自我修订系统。它白天和你工作，晚上整理日志；它不会因为一句随口的话就改写长期认知，但会把连续出现的模式提成候选；它能自动做草稿，但关键边界仍然交还给人确认。
这才是我理解里的“可控自我进化”。
为什么这对个人尤其重要
企业级 agent 当然也需要这些东西，但对个人来说，这件事反而更关键。因为企业系统往往还能依赖流程、角色分工、审批链条、组织知识库来兜底；而个人助手一旦做不好，问题会直接落到一种更微妙的层面：它会显得不懂你。
而“不懂你”在个人场景里是非常致命的。因为你真正想要的，并不是一个永远能答对百科问题的模型，而是一个在日常协作里越来越省你心的搭档。它知道你更重视什么，知道你不喜欢什么，知道哪些事该主动、哪些事该保守，知道什么时候应该帮你推进，什么时候应该闭嘴。
这些都不是知识问题，而是长期协作问题。而长期协作，本质上就是 Harness 问题。
所以未来真正的分水岭，不是谁的模型更大，而是谁的 Harness 更成熟
我现在越来越相信，接下来个人 AI 助手真正的差距，未必首先体现在模型参数上，而会更多体现在 Harness 上。
同样一个底层模型，如果它只有 context，没有 memory；只有 prompt，没有 skill；只有回答，没有 update loop；只有即时反应，没有长期修订，那它永远更像一个聪明的陌生人。
反过来，如果一个系统有好的 memory 分层，有成熟的 skill 机制，有清晰的工具边界，有稳定的反思和更新节奏，它哪怕底层模型不是最强，也更容易长成一个真正可合作的助手。
因为人和人之间的长期默契，从来不是靠“每次都重新介绍自己”建立起来的，而是靠共同记忆、共同套路和不断修正形成的。个人 AI 助手也一样。
最后一句话
如果要我用一句话概括这次变化，我会这么说：
Context Engineering 让模型在这一轮更聪明，
Harness Engineering 才让它在长期协作里，慢慢变成“你的”。
真正值得投入的，不只是把上下文喂得更满，而是让记忆会更新，让技能会进化，让 AI 在长期合作中形成自己的工作方式。
这才是下一阶段更重要的事。