微软 CoreAI 副总裁 Marco Casalaina 说得最直接：模型本身只一个 token 接一个 token 地预测，自己不做任何事，要被嵌进某种 harness 才能行动；M365 Copilot、GitHub Copilot 各是一种 harness，今天看到的效果来自 harness 与模型的配合⁠1。

Orca 创始人梁津晶给了更技术化的版本：harness 是把「一个 input 对一个 output」的 agent 做成 loop，这个 loop 还能调用工具、读 bash、搜网页，是 loop 与 tool use 的组合；Codex、Claude Code 背后的这套东西就是 harness，Pi、OpenCode 也算⁠2。她还区分了 ADE：ADE 不直接接模型、不自己做 loop，而是把 loop 交给现成 harness，自己专注人和 agent 之间的调度与审阅⁠2。

立正在节目里区分狭义和广义：狭义是 OpenAI、Anthropic、Cursor 文章里定义的那套东西，讲怎么在时间、数量、人机交互上更 scalable；国内则把 2024 年之后发生的所有事都叫 harness。他的疑问是：那它和 agent 还有什么区别⁠3？

他列举广义 harness 吞进去的内容：agent loop、工具、agent architecture、context engineering，几乎所有跟模型有关的东西⁠3。他的判断不是「不该学」，而是「什么都包含时，这个词就没有意义了」，不如讨论 MCP、LangChain 这类指向具体的概念⁠3。同一段里他还提到，harness engineering 本质上是给 agent 创造更好的环境，让它更好地用工具、多步决策、自我迭代⁠4。

立正在与韦晓亮对谈中纠正了一个说法：不是「harness 稳定、模型随便换」，而是「模型加 harness 可以随时切换」——今天用 Claude Code，明天换 Codex，同一份业务经验、任务标准和上下文应该还能用⁠5。这是 AI 对该表述的应用性解读：如果你的经验只写进某个工具的配置里，换工具就归零；写在工具之上的 skill 和上下文里，模型变强、harness 变强你都能受益。

另一个可观察的检验：Garry Tan 把 harness 和 Skill Files 等并列成方法论组件，立正把这套做法概括为「给动词穿上名词的外套」——名字让软性经验看起来像可学的硬技术⁠6。所以听到「我们已经在用 harness engineering」时，值得追问的是具体指 loop、工具、上下文还是验收标准；《AI已经用得很好，为什么还是怕被淘汰？》⁠7里立正也提到，有人被问 harness engineering 是什么时答不上来⁠7。

立正署名文章把上下文管理拆成三层记忆：工作记忆是当前任务直接需要的，项目记忆是这个项目积累的经验和决策，组织记忆是跨项目的长期知识。原始会议纪要、Slack 讨论、设计文档属于 raw context，需要定期提炼成有效经验、踩过的坑和判断标准。文章还强调渐进式加载：不能把所有东西一股脑塞进窗口，而要建索引、做分类、设计加载策略，让 AI 自动找到需要的那部分，不多不少⁠1。

同一篇里还有一层概念图，用来标出团队的上下文现在散落在哪里、哪些该被日常调用、哪些该长期沉淀、哪些需要定期更新。作者把它比作给客户看的 marketing calendar：先看清现状，再谈技术落地⁠1。

立正在课程更新里把可积累的资产归成五类：工作空间、可复用的 skill、结构化知识资产、多 agent 组织和个人判断。具体组织方式是用 facts（事实）、skills（做法）、perspectives（判断）区分私有上下文，用 progressive disclosure 按需加载，用 backflow 把每次纠正沉淀回系统⁠2。

他在对话里也表达过相近的区分：文件是 what，即有什么信息；skill 是 how，即这件事怎么做；再往上是 resolver，遇到任务时决定调用哪些东西。他还说，人类积累的 context 往往严重不足，散在聊天工具、会议和文档里，把它们组织好、沉淀好本身就是很重要的一环⁠3。这些是他本人在节目中的陈述，不是对某位嘉宾观点的转述认可。

如果目标是积累自己的上下文资产，可以先做两件成本低的事。一是把值得回看的材料落成 Markdown 存在自己的目录里，能搜索、能修改、能换模型继续加工；立正谈录音整理时明确说，工具可以换，这些积累要跟着自己走，不能被工具绑架⁠4。二是写结果类 skill 而不是风格类 skill：把该给的工具、对结果的要求、边界和案例交给 AI，而不是教它一步步做事⁠5。

判断是否值得投入时，可以问一句：这一步具体让哪一段变好了？是材料更容易找到，还是纠正能被记住？如果答不上来，可能只是多买了一件要维护的东西⁠4。这是 AI 基于上述材料做的应用推演，不是原文给出的检查清单。

立正在谈 AI 写脱口秀段子时说，大家写 prompt 太懒，只写“你是一个优秀的脱口秀演员，帮我写个段子”是不够的；要先讲清想要的风格、参考的人、原则，再把平时沉淀的故事和想法交给它⁠1。他还提出一个检验办法：把 AI 当成一个聪明但对你的工作一无所知的人，问自己“要完成这件事，我需要告诉他什么”，多数时候问题出在关键信息没给到⁠1。这是 AI 对“人味从哪来”的综合判断：人味首先来自只有你才有的观点、经历和取舍，而不是来自形容词。

老冒讲过一个实验：一篇文章每行字都是 AI 写的，但观点是他的、也是他认可的，结果进了 Hacker News 前十；他随后照同样模式又写了几篇，都没有效果⁠2。他自己的解释是，AI 帮他把观点组织得更好，而不是替他产生观点⁠2。这提示一个可操作的边界：让 AI 承担“把想法写好”的部分，把“想说什么、为什么在意”留给自己。不过这只是他一次实验的观察，重复失效也说明光有模式不够。

署名立正的文章谈 taste 时建议：找“相似但质量不同”的样本放在一起比较，问哪个更好、为什么，差异才是判断力的入口；同时先保留第一反应，再解释，别让解释压过感受⁠3。同一篇还强调要动手做并反复改，因为只有做才会遇到真实约束⁠3。把这套方法用到 AI 写作上（以下是 AI 的应用推演）：与其笼统要求“更有人味”，不如拿两版稿子对比，指出哪句假、哪句空、哪句是你真会说的话，再让 AI 按这个差异改。这样你给的是可核对的判断，而不是一个形容词。