长时运行Agent与开源Harness

长时运行 Agent 与开源 Harness 来自 @Sumanth_077 分享：当 Agent 从"短演示"走向"长任务"，决定成败的不再是模型本身，是包裹模型的运行时—— Agent Harn...

长时运行 Agent 与开源 Harness 来自 @Sumanth_077 分享：当 Agent 从"短演示"走向"长任务"，决定成败的不再是模型本身，是包裹模型的运行时—— Agent Harness；而 Sam Altman 的观点"有理由偏爱开源 harness"正是作者内容的出发点。 一个可用的 Agent 由四块积木组成：模型（推理）、MCP 工具（连接外部系统）、Skills（任务执行规程）、Sandbox（隔离执行环境）；而长时运行还需要另外四样：子 Agent、上下文管理、审批检查点、持久会话。 # 技术主线：一个 Web 研究 Agent 的完整运行解剖 以 TrueForge（TrueFoundry 的开源 harness）上的研究型 Agent 为案例，逐层拆解运行机理： 1. 执行循环 模型收到任务 → 决定调用工具 → harness 执行 → 结果回传 → 模型再推理 → 循环直至完成。写一个基础循环只需一下午，真正的工程难点在于让循环"活下来"：模型无限调工具怎么办？单次搜索返回 2 万 token 怎么办？浏览器中途关闭怎么办？——这些都是 harness 问题，不是模型问题。 2. MCP 与渐进式披露 生产级 Agent 可能挂载数百个工具，若把全部 schema 塞进每次请求，上下文窗口在开工前就被耗尽。解法：先让模型"知道能力存在"，真正需要时才加载完整定义。 3. Skills：规程与能力分离 MCP 工具描述"能做什么"，Skill 描述"该怎么做"。30 种工作流的完整规程不应全部常驻系统提示词，而是按需加载，保持基础上下文精简。 4. Sandbox：执行与上下文的双重隔离 代码不在 Agent 服务器上直接运行，而是在隔离沙箱中执行。沙箱同时承担上下文减负功能：海量搜索结果在沙箱内处理、写入文件，只把摘要或引用回传给模型。 5. 上下文管理四板斧（长任务的真正瓶颈） · 渐进式披露：工具/技能按需加载 · Code Mode：大结果用代码过滤转换，不原始回传 · 大结果外置：写入文件，模型只持预览与引用 · 压缩：越过阈值后，将早期历史摘要化，牺牲逐字细节、保留任务状态 6. 子 Agent：用隔离换并行 比较三个开发工具时，为每个工具派生独立子 Agent：各自持有独立上下文、并行研究，只把结论回传父 Agent。父上下文因此保持小巧。文章也给出了诚实的边界：若任务单窗口可装下，拆分反而增加编排复杂度与失败面——子 Agent 适用于真正并行或子任务会污染主上下文的情形。 7. 审批门：运行时规则，而非提示词请求 敏感操作（合并 PR、改基础设施、发消息）的执行路径被改为：模型决定 → harness 暂停 → 人工审查 → 继续或终止。关键区别在于：提示词里的"删除前先问我"是模型可以选择违背的指令，而审批门是 harness 层面的硬性规则，模型无法绕过。 8. 事件流：让运行脱离客户端而存活 长任务不能假设"浏览器连接 = 任务生命周期"。harness 将会话的每一步持久化为有序事件流：浏览器关闭，服务器继续执行；重连后可断点续传。副产品是可回放的完整执行轨迹——最终答案告诉你发生了什么，事件流告诉你为什么。 Sumanth @Sumanth_077 x.com/i/article/2092… 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 0 👀 445 📊 1 ⚡