把长任务 Agent 写成可运行协议

这篇文章真正说的，是 Agent 如何跨过“单轮聪明”

大多数关于自主研究 Agent 的讨论，容易落到一个很诱人的叙事：模型越来越强，所以研究可以自动化。但 AutoResearch 给人的启发恰好相反：模型能力只是地基，真正决定长任务能否跑完的，是模型之外的协议。

所谓协议，不只是“你是一个严谨的研究员”这种角色提示词，而是完整的运行制度：任务怎么定义，状态存在哪里，下一步依据什么决策，卡住多久算停滞，谁来检查引用，哪些分数可以被推翻，运行中断后如何恢复。

这也是它对工程团队最有价值的地方。我们不必急着相信“AI 可以全自动做研究”，但可以非常务实地学习它的结构：当一个 Agent 要连续工作几十小时、跨多个方向探索、不断产生中间结论时，必须把工作从对话上下文里搬出来，变成文件系统里可审计、可恢复、可验证的工作流。

长任务 Agent 的核心不是更长的上下文，而是更可靠的外部记忆和更诚实的验证门。

长任务 Agent 最常死在三种地方

AutoResearch 框架页把长任务失败归纳为几类问题：认知循环、停滞、运行脆弱。换成工程语言，它们分别对应“策略层没有退出条件”“执行层没有下一步驱动”“运行层没有持久化状态”。

这三个问题不是研究任务独有的。写代码、整理知识库、做竞品分析、批量审查文档、跟进 issue，都会遇到。只要任务无法在一次回复里完成，Agent 就会从“回答问题”进入“管理过程”。而过程管理不能靠模型自觉，必须靠外部结构约束。

Skill 不应该只是提示词，而应该是状态机

AutoResearch 最值得借鉴的设计，是把 SKILL.md 看成一种运行协议。它不是把一堆最佳实践塞进提示词，而是规定 Agent 在不同状态下该读什么文件、写什么文件、触发什么检查、什么时候进入恢复路径。

这就是“Skill 协议化”的本质：把隐含在优秀操作者脑子里的工作习惯，转成 Agent 必须遵守的状态机。一个好 Skill 至少要回答四个问题：

状态落盘，是长任务 Agent 的第一性原理

一旦任务跨过单次对话，文件系统就应该成为事实源。聊天窗口适合协调，文件适合承载状态。AutoResearch 的文件思路可以抽象成四类：

注意这里的关键不是文件名，而是职责分离。任务规格是“意图”，进度是“当前位置”，发现是“证据”，尝试方向是“负知识”。很多 Agent 系统只记录成功发现，不记录失败路径，于是下一个 Agent 会重新踩一遍同样的坑。

research-run/
├── task_spec.md              # 任务目标、边界、验收标准
├── progress.json             # 当前阶段、下一步、阻塞状态
├── findings.jsonl            # 证据日志：一行一条发现
├── directions_tried.json     # 已尝试方向和失败原因
├── artifacts/                # 中间产物、图表、草稿
└── reviews/
    ├── citation_audit.md     # 引用核查
    ├── reproduction.md       # 可复现性检查
    └── external_review.md    # 独立审阅意见

真正可靠的自动化，必须允许自己被证据打脸

AutoResearch 复盘里很有意思的一点，是系统不会永远维护漂亮的上升曲线。引用核查、外部审阅或复现实验发现问题后，原本的结论和评分可以被拉低。这一点比“分数越来越高”的宣传更重要。

对 Agent 工程来说，验证不是最后写一句“已完成”，而是一个独立权力中心。执行者负责推进，验证者负责找茬，状态文件负责记录验证结果。只有当验证结果能反过来改变计划、降低置信度、甚至推翻结论时，验证才是真的。

可以迁移到任何 Agent 工作流的三层验证

多 Agent 不是答案，任务形状才是答案

读这类文章很容易得出一个过度简化的结论：既然一个 Agent 会卡住，那就派很多 Agent。实际上，多 Agent 只是并行化和视角隔离的工具，不是质量保证本身。

如果任务可以拆成相互独立的搜索、实验、文件修改，多 Agent 很有价值；如果任务需要维护一条长推理链、持续整合上下文、反复打磨同一个理论，单 Agent 的深度串行反而可能更稳定。关键不是数量，而是角色之间是否有明确的信息边界和交付契约。

如果把它迁移到自己的 Skill 仓库，可以这样落地

对一个维护 skill、sub-agent、commands 和文档的知识库来说，最直接的启发是：不要只写“怎么做”，还要写“做的过程中如何保留状态、如何验证、如何恢复”。下面是一个可迁移的最小模板。

这类协议化 Skill 的价值，不是让 Agent 更听话，而是让团队有能力审计 Agent 的过程。一个人类 reviewer 不需要翻完整聊天记录，只要看 task_spec.md、progress.json、findings.jsonl 和 reviews/，就能知道任务有没有真实推进。

反停滞循环可以写得非常机械

while task.status != "complete":
    state = read("progress.json")
    evidence_before = count_new_evidence()

    next_action = choose_action(
        task_spec="task_spec.md",
        tried="directions_tried.json",
        findings="findings.jsonl"
    )

    run(next_action)
    write_progress()
    write_findings()

    evidence_after = count_new_evidence()
    if evidence_after == evidence_before:
        state.stall_count += 1
    else:
        state.stall_count = 0

    if state.stall_count >= 3:
        mark_current_direction_as_stale()
        choose_different_direction_or_escalate()

这里的“机械”是优点。长任务里最危险的不是 Agent 不会想，而是它太会解释自己为什么还在同一条路上继续想。协议要做的事，就是在某些地方剥夺它继续自我合理化的自由。

值得学，但不能神化

AutoResearch 这类框架最容易被误读成“全自动科学家”。更稳妥的理解是：它展示了一套长任务 Agent harness 的形状，但不自动保证结论等同于外部同行评审。

所以，最健康的态度是：把它当成工程模式库，而不是能力承诺。我们可以吸收它的状态管理、反停滞机制和验证闭环，同时继续对产出的事实性保持怀疑。

最后的启发：Agent 的下一层竞争，是过程质量

当模型能力越来越接近，真正区分 Agent 系统的，会是模型外面的工程环境：任务能否被清楚表达，状态能否恢复，验证能否独立，失败能否留下负知识，团队能否复用一套可靠协议。

这也是 AutoResearch 对所有 Agent 工程最朴素的提醒：不要把复杂工作塞进一个更长的 prompt。把它拆成协议、状态、证据和验证门。这样 Agent 才不是在聊天窗口里表演努力，而是在一个可审计的系统里推进工作。