总结Harness世界观：Runtime越笨，架构越稳定，把智能下沉到模型，把确定性留给框架
很多人谈 agent 工程化，习惯从“模型更强”开始讲。 但真正的分水岭，往往不在模型，而在 harness：那层把模型包进现实世界的运行时外壳。
harness 的目标只有一个：让模型在一个可控、可审计、可扩展的系统里持续干活。 为了这个目标，最反直觉、也最有效的一条原则是：
Runtime 越笨，架构越稳定。把智能下沉到模型，把确定性留给框架。
下面把这套世界观拆开说清楚。
三代架构的迁移：从“流程驱动模型”到“模型驱动流程”
把过去几年常见的产品形态按控制权划分，大概是三代：
- Chatbot：无状态问答
- Workflow：代码写死 DAG，模型只是流程中的一个组件
- Autonomous Agent：模型拥有控制循环，运行时只是执行器
第三代的关键变化不是“加更多工具”，而是控制权翻转：框架不再告诉模型下一步做什么，而是让模型决定下一步做什么，框架只负责执行、约束、记录。
这一步一旦发生，harness 的设计哲学也必须跟着变。
TAOR/控制循环：Orchestrator 不需要聪明，只需要可靠
一个典型的自主循环可以压成四步：Think → Act → Observe → Repeat。 看起来简单，但它决定了谁负责什么。
当 Orchestrator 被设计得极其“笨”，它只做三件事：
- 驱动循环
- 执行工具调用
- 把观察结果喂回去
而所有的推理、决策、以及“何时停止”，全部交给模型。
这会带来一个直接好处：运行时本身几乎不承载领域知识，因此：
- 更不容易写死错误逻辑
- 更不容易在模型升级时被反复推翻
- 更容易跨场景复用
- 更容易做安全审计（因为它的职责清晰）
所以“笨”不是贬义词，而是一种工程上的自我克制：把不确定性交给模型，把确定性放在框架里。
工具哲学：不要造 100 个工具，给它一个 Shell
很多人做 agent 的第一反应是：给模型配一堆专项工具。 但另一条更稳的路线是：只给少数能力原语——读、写、执行、连接。
其中最关键的通用适配器是 shell。 给模型 shell 的意义在于：你不必预测未来的所有工具形态，只要保证“人类开发者会用的工具”都能通过 shell 组合出来。
这条路的底层假设是：
- 模型会越来越强
- 框架应该越来越薄
- 硬编码脚手架应该随着模型能力提升而被主动删除
如果每次模型升级，你都要往框架里加更多“聪明编排”，那通常意味着你在对抗模型，而不是利用模型。
上下文不是越大越好：越干净越好
Agent 系统最普遍的失败模式之一，是上下文塌陷：对话越来越长，噪音越来越多，记忆退化、幻觉上升，模型在自己制造的垃圾里迷路。
所以把 context window 当作稀缺资源来管理，比追求更大窗口更重要。常见的三道防线是：
- 自动压缩：到一定占用比例就摘要替换原始对话，释放空间但保留关键决策
- 子 agent 隔离：把重型探索/研究卸载给独立上下文预算的子任务，主上下文只收摘要
- 缓存经济学：把“缓存失效”当作财务问题来治理，尽量避免系统提示与模式切换导致的 cache-break
这一层的核心不是“更聪明”，而是“更节制”：把上下文当预算，把信息当资产，把噪音当债务。
记忆不是背包，是索引：能推导出来的就不存
多数人想象的“记忆”像一个更大的背包：装得越多越好。 但更可持续的设计是：记忆是一套索引系统，而不是存储系统。
原则可以很硬：
- 能从代码库/日志/文件里重新推导出的信息，不该存进记忆
- 记忆要分层加载（组织策略、项目约束、用户偏好、自动学习、会话上下文、子 agent 专项记忆）
- 记忆必须允许自我编辑：去重、重写、剪除矛盾与过期内容
原因很简单：对 agent 来说，记忆越多不一定越强，可能只是更贵、更慢、更容易错。 记忆真正的价值是“减少不可逆的重复成本”，不是“复述一切细节”。
权限与信任：不是安全模块，而是 UX 设计
Agent 要走向生产环境，权限设计决定生死。
好的权限系统往往不是“允许/禁止”两档，而是一条可组合的信任光谱：从只读、到每次确认、到自动批准编辑、到白名单自动执行、再到组织托管下的完全放行。
这不是安全团队的洁癖，而是产品逻辑：
- 个人开发者需要速度
- 企业需要可控
- 同一个框架要同时服务两种世界，就必须把信任设计成可渐进、可组合的体验
所以权限系统的难点是“让用户敢用”，而不仅是“理论上安全”。
多 agent：从“派遣子任务”到“团队协作”
当上下文预算成为瓶颈，多 agent 不是锦上添花，而是必然：
- 子 agent：独立上下文、独立循环、独立记忆，完成后只回摘要
- Agent teams：多个实例共享文件系统，通过任务列表、单播/广播消息、以及完成前的质量门控 hook 来协作
这里同样体现了 harness 世界观：框架提供最少但可靠的协作原语，复杂性留给模型与任务本身。
结尾：harness 的终极目标，是“让架构随模型变强而变薄”
把智能压到模型里，把确定性留给框架里，最终带来一个很强的演化方向：
- 模型越强，运行时越不需要聪明
- 脚手架越少，系统越稳定
- 规则越清晰，扩展越可控
- 边界越明确，自治越安全
这就是 harness 的世界观： 让 runtime 做“笨但可靠”的底座，让模型承载“聪明但不确定”的决策。