第三十章 展望：Harness OS、Agent 组织与持续进化
证据地位：本章为作者的条件性展望，结合截至 2026-09-19 已核验研究提出观察方向，不代表这些路径必然发生或已获生产验证。
若长期任务、工具种类和治理需求继续增长，Harness 可能承担更多类似操作系统的职责：调度执行者，管理上下文和能力，隔离计算，记录外部变更，并协调版本与恢复。这个比喻有助于分配责任，却不要求复刻传统 OS。对单一、低风险流程，轻量工具或确定性工作流仍可能更合适。
1. 模型与 Harness 可以共同设计
统一任务、动作和证据语义，不要求所有模型使用相同工具格式。企业可以保留稳定的内部合同，再按模型特点生成工具视图、上下文与停止规则。是否值得维护这些适配，取决于实测收益能否覆盖兼容和迁移成本，而不是“模型无关”与“追求效果”只能二选一。
HarnessDev 发现换执行模型可能改变冻结 Harness 的表现；JIT-Agent 则训练生成器为任务构造 Harness，并冻结底层执行模型。前者测产物迁移，后者测生成体系，不能用同一“通用性”标签抹平差异。这使协同设计值得研究，也要求每次发布留下模型、生成器、配置和经验库的版本。HarnessDev v1、JIT-Agent v2
观察信号应是：适配后的条件收益、统一合同覆盖率、换供应商的工作量与回归成本。如果通用接口已能达到目标，维护多个特化版本反而可能成为负担。
2. Agent 组织首先是依赖和交接问题
跨越单轮聊天的任务，需要明确身份、预算、工作区、产物和责任。多个代理可以围绕任务分工，但角色名称不会自动创造权限边界，工作单元更多也不自动代表协调更有效。
HoH 在固定基础 Harness 下迭代软件项目，以产物和证据延续工作；Stellar Colosseum 针对长证明维护相互依赖的子问题，通过反证与验证驱动局部修复。二者提示了不同组织需求：软件项目要追踪增量和重开问题，研究任务还要追踪一个论证变化会使哪些结论失效。这些是特定研究设计，不是任意多代理组织都有效的证明。Harness-of-Harness v1、Stellar Colosseum v2
人可能更多地负责目标、规范、例外和证据审查，但转变能走多远，仍由结果可验证性与业务责任决定。流程依赖口头约定、共享账号和不可观察系统时，增加代理数量可能只是扩大混乱。
3. 环境既可能是资产，也可能是债务
权威数据可查询、工具参数清楚、日志可追溯、测试表达业务约束、审批可由系统调用，这些条件可以让不同模型持续受益。它们往往比为一次演示堆提示更值得维护。
环境也可能积累负担：针对旧模型的提示补丁、无法撤销的技能、缺少来源的记忆、无人负责的适配层。应比较每项资产的复用收益与测试、维护、删除传播和退出费用。成熟知识可以变成工具默认值或校验器；持续学习不要求经验库和配置永远膨胀。
4. 自我进化要拆开“改什么”与“谁来决定”
Self-Harness、HarnessBank v2、Living-Harness 与 HSI 提供了不同对象的受限实验信号，具体机制与限制见第十九至二十四章。新研究又扩展了诊断、生成和效率目标：HarnessEvolve 依赖经检查的参考轨迹，Ecdysis 聚合跨任务失败，SoL-Pi 搜索减少往返与上下文费用的机制，同时存在得分让步。不能把它们概括成同一条已证实会持续增长的路线。HarnessEvolve v1、Ecdysis v1、SoL-Pi v1
RSI 路线图讨论改进过程的自主性，包括谁选择策略、获取经验和改进改进机制；本书四类对象回答的是改了什么。某个系统自动改提示，不代表它已经自主定义目标、生成可靠评测或接管治理。路线图是研究方向，不能因论文标题就宣布人类已退出改进回路。RSI 路线图 v2
低风险表面能否扩大自动晋级范围，要看独立验证覆盖、跨轮泄漏控制、长期事故率和撤销演练是否改善。若这些条件停滞，更合理的结果可能是收缩权限或保留人工选择。
5. 长时系统仍有未解决的问题
长期运行会积累小错误，跨代理交接可能放大污染，插件与技能可能把一次注入变成持久行为。删除源经验后，摘要、缓存、训练数据或权重仍可能保留影响；紧急撤销又必须压过版本粘性。第三十章并不能靠一个“系统可治理”的结句替这些问题作安全保证。
值得继续研究的具体问题包括：可移植检查点怎样描述外部动作状态；多条证明或方案如何组合验证；封存测试在反复查询后何时失去独立性；训练数据撤销后如何验证派生模型处置；质量与费用的权衡能否在长期任务分布中保持。衡量进展需要固定单位、对照与完整账目，而非只看一次最好结果。
6. 三条路径及其反证条件
| 可能路径 | 支持它的观察信号 | 应减缓或转向的信号 |
|---|---|---|
| 交互工具为主，人提交关键动作 | 人工复核负担可控，任务多变且难形式验收 | 审核等待成为主要瓶颈，重复任务已有可靠检查 |
| 共享企业任务与证据服务 | 多运行时的接入、迁移和恢复成本下降 | 统一层增加复杂度，关键语义仍无法兼容 |
| 持续实验与有限自动晋级 | 新任务确认收益可复现，事故受控，撤销有效 | 测试反馈被反复利用，收益靠额外费用或更宽权限取得 |
这些路径可以并存，也可能受技术、商业和治理约束而转向。支持多个运行时不是成熟的必要条件，自建完整平台也不是每个组织的目标。应保留采购、受限自研、确定性流程和人工服务的经济对照。
7. 把判断留给可观察结果
本书倾向于把 Harness 看作连接模型能力与组织责任的基础设施。这个判断是否有用，应由具体交付回答：产物是否满足合同，外部动作是否确认，出错后能否停止和恢复，改进是否在独立任务上复现，总费用是否可接受。
如果未来更强模型使某些支架失去价值，就应删掉那些支架；如果任务仍缺可验证结果，就应限制自治范围。值得持续建设的是清楚的接口、可靠证据和可执行的纠错能力，让组织有条件判断何时继续自动化，何时停下来。