源于一个比喻, 模型是 horse, 人是 rider, 中间那层是 harness. 从字面来看 harness 是指为确保模型按预期行为运行而构建的约束框架与支撑体系. 至少可以从两个角度理解.

• 产品侧: Agent 产品 (如 Claude Code) 自己做的 harness (Anthropic 在 Scaling Managed Agents 进一步把有关大模型决策的部分称为 harness, 而 session, tools, sandbox 等独立为其他模块).
• 用户侧: 开发者使用 coding agent 时为了保证复杂项目受控做的脚手架 (比如 SDD, ralph loop 等).

随着模型能力变化, harness 也需要改变, 如 Harness design for long-running application development.

书接上回, 增补 Auto Memory 保存和召回细节; 以及介绍 auto-dream.

WebSearch 调用服务端的搜索工具, WebFetch 本地抓 URL、HTML 转 markdown、再交给一个小模型按 prompt 提炼.

延迟 tool 加载

用 FileReadTool 统一读文件. 如果用户使用 @ 提及文件或目录, 则先把它们变成 attachment 再在发给模型前重建成一组“伪造的上下文消息”.

分为 Session Memory和 Auto Memory (跨 session).

若干层压缩.

2020 年时想的问题, 一直搁着. 今天突然想起来了.

瑞士轮编排通常要满足这些约束:

• 匹配过的两人不再重遇 (硬规则)
• 同分或近分者优先匹配
• 先后手尽量均衡 (棋类: 保证选手执黑 / 执白次数大致相等)
• 满足上述条件后适度随机 (部分严肃比赛不做随机)

要找到一组同时满足上述约束的匹配并不 trivial. 一种朴素做法是按经验法则先构造一组匹配, 再检查是否满足约束, 不满足就回溯重试 (trial and error). 早年 FIDE (国际棋联) 的裁判就是这样手工编排的. 这种启发式搜索的复杂度已经很高; 若改为暴力枚举所有可能的匹配再随机抽, 由于匹配数量随人数呈阶乘级增长, 更不可行. 因此需要更高效的算法求解.