LongHorizon-Harness

一句话定位

一个让 agent 能连续操作电脑几小时而不丢任务状态的开源执行框架：把"任务干到哪了"从对话上下文里搬出来，用管理-执行-审计（MEA）三角色循环，每轮只在干净上下文里执行、只认审计者从环境验证过的事实，从根上掐断"agent 误以为自己干完了"这条错误传播链。

做这个东西的人

高德（AutoNavi）机器学习团队 AMAP-ML 开源，论文署名 DreamX Team, Alibaba Group，第一作者 Ziyu Ma。MIT 协议，代码创建于 2026-08-04，配有 arXiv 论文（2608.01964）。属于国内大厂地图团队的 agent 基建研究。

判断：高德/阿里做这个不奇怪——地图业务是天然的"长任务 agent"场景（多步规划、跨工具调用、需要环境反馈）。它是实验室研究项目，不是创业项目。

它到底能做哪几件事

• Manage-Execute-Audit 三角色循环 → Manager 维护任务状态并派子任务（只读报告，不碰环境）；Executor 在全新上下文里执行单一子任务（唯一允许改环境的角色，执行后轨迹与推理丢弃）；Auditor 用只读工具独立核查环境是否符合验收标准（看不到 Executor 的推理与自评，改动受保护状态即触发 integrity violation）
• 新鲜上下文执行 → 每轮 Executor 从零开始，只接收当前子任务和审计证据，防上下文腐烂
• 持久化已验证状态 → 任务状态由 Auditor 从环境独立写入，标记 completed / pending / blocked / untrusted，带证据
• 无失忆重置 → 执行错误只留在当轮，被下一轮审计暴露或根本不进记录
• 后端无关 → 三个角色可分别接 Claude Code、Codex CLI、Gemini CLI、mini-SWE-agent 等任意 harness
• 可用性 → Python 3.10+，uv tool install lh-harness，CLI 带实时 dashboard

它在替代什么旧行为

替代的是现在所有 agent harness 的默认架构：把执行轨迹、任务状态、完成度自评全塞进一条越来越长的上下文。这套"懒政"有三个致命问题——状态一长就难追踪、模型误以为某步完成会让错误自评污染后续所有决策、上下文无限膨胀成本爆炸。

LongHorizon-Harness 把"状态"从上下文里抽出来，变成只由环境验证事实更新的外部对象。它替代的不是某个工具，而是一种编排范式。

判断：这是它对所有做 agent 的人最大的贡献——问题被重新定义成"任务状态管理"，而不是"让模型更聪明"。

商业模式

无。纯开源（MIT）+ 论文，无托管服务、无收费。

判断：这是大厂实验室的公开研究，变现路径不在代码本身——长任务 agent 能力如果内部验证成功，收益体现在高德自身的产品上。

硬数字

• 705 star / 83 fork / 17 open issue，MIT，创建于 2026-08-04（约 10 天，首日 166 star）
• arXiv 2608.01964，2026-08-03 提交；Hugging Face Daily Papers 2026-08-04 第 2 位（131 赞）
• 基准（同模型同后端，只换 harness）：
  • WeaveBench（114 任务）：51.8% → 80.7%（Qwen 3.7-Plus）
  • Terminal-Bench 2.1：69.7% → 77.2%
  • OSWorld 2.0：2.8% → 8.3%（3 倍）
  • OSWorld 2.0 子集（34 任务，Claude Opus 4.7）：20.6% → 35.3%
• 成本：Manager 只占 2.0%-8.1% token；审计占 19.4%-38.1%；Terminal-Bench 上总 token 比基线少 24%
• 团队人数、任何商业化计划：未披露

四维评估

判断

这是把 agent 从"会不会做"推到"能不能稳稳做完"的关键一块基建。 现在主流 agent 框架都在赌单条长上下文，LongHorizon-Harness 证明把状态外置、加一个只读审计者，能在不改模型不改后端的条件下普遍提升长任务成功率——这个结论如果可复现，会改变 agent 基建的默认架构。

可迁移的规律：给任何自动化 agent 加一道"只认环境事实"的校验门。 Executor 干完活说"我完成了"，别信；让一个独立的、只读的、看不见 Executor 自评的审计者去真实环境里验证。这是反幻觉的工程化版本，比"让模型自我反思"可靠得多。任何长流程 agent 都可以直接抄这道闸。

局限要看清：这套方法依赖"环境状态可被独立读取验证"——终端、OS、Web 这种有回显的场景适用，开放创作、模糊需求场景没有 ground truth 可审；每一步多一次审计调用，延迟和 token 成本上升；Manager 自身也可能成为新的长程瓶颈。基准全部偏"可校验"场景，泛化性证据还不足。

下一步看什么

① stars 三个月后能否破 3000——"长任务 harness"这个基建品类是否被市场接住 ② 是否有非学术团队公开复现基准（企业用真实业务验证，而非 benchmark） ③ 是否出现企业托管版或与主流 agent 框架的官方集成——从论文走向产品的信号

可借鉴的做法

架构逻辑：任何做长流程 agent 的团队，第一件事把"任务进度/子目标完成度"抽成结构化的外部状态（数据库/状态机/todo），而不是指望模型从几万 token 历史里回忆。状态外置是一切的前提。

执行策略：每步给执行器一个新上下文，只喂当前子任务 + 必要证据。把"单条超长上下文硬扛"改成"短上下文 + 外部状态"，能显著降低噪声累积。

适配层：用薄适配层接不同模型/harness、不动原生 loop——把调度逻辑与执行后端解耦，别为了接新模型重写整套流程。

结论

值得关注。 方向正确、证据扎实（跨模型跨域一致增益）、来自有真实场景的团队。但它是研究项目不是产品，泛化性和成本账还要真实业务来验证。记下来，三个月后对照上面三条看它往哪走。