读 Deli AutoResearch：长程 Agent 需要的不是更强模型，而是工程脚手架

这篇文章基于本地手册《Deli_AutoResearch SKILL.md 原文对照译注手册》整理。原手册做的是逐句对照译注：保留英文原文、给出中文翻译，并对设计意图、术语和跨节关系做解析。

我不打算把译注全文搬过来。真正值得写成博客的，是它背后的一个判断：

长程 agent 的失败，很多时候不是模型不够聪明，而是缺少工程脚手架。

这句话很重要。因为它把问题从“换更强的模型”移到了“给 agent 一个不会自己把自己拖死的运行协议”。

三种失败：循环、停滞、脆弱

手册开篇把长程代码 agent 的失败归成三类：

1. 认知循环：agent 连续几轮都在相似方向上试探，收益越来越低，却无法自己跳出局部最优。
2. 停滞：agent 做完一块工作，输出总结，然后等用户反馈。外部看 session 还活着，轮询也在跑，但任务其实已经停了。
3. 运行时脆弱：上下文压缩、会话关闭、定时器依赖等问题，会悄悄切断循环，而系统默认可能察觉不到。

这三类问题都很熟悉。我们平时用 coding agent 时，经常看到类似现象：它不是直接崩掉，而是“看起来还在工作”；它不是完全不会做，而是在一个方向上反复打转；它不是没有状态，而是状态散落在对话历史里，被压缩或截断后就失忆。

Deli AutoResearch 的答案不是“再提示一下”，而是加协议、加状态、加监控。

第一层：行为不能靠自觉，要靠协议

手册第 2 节提出五条行为约束，我理解为把 agent 从“好像会自律”改造成“没有机会停在错误姿势”：

• Zero interaction：一次运行期间不向用户提问，不用提问工具，不以问题结尾。
• Ready means execute：准备完成就执行，不要问“要不要提交”。
• Callback means report-alive：每次回调第一步先更新自己的 last_seen，再检查存活。
• Persist state to files：进度写入 state/ 文件，不依赖对话记忆。
• Guardian / worker separation：守护者只做存活检查、重启、轻推，不越权读写 worker 状态。

这里最反直觉的是第一条和第二条。人类协作者会觉得“问一下更稳”，但对长程 agent 来说，“问一下”就是停滞入口。

所以这套协议要求 agent 自行消解歧义，并把判断写入 level=decision 日志。也就是说，系统不是不允许不确定，而是不允许“不确定所以停下来等人”。

第二层：用 fresh session 打断上下文污染

手册第 3 节的架构核心是：一个 orchestrator 监控多个独立的 fresh-session 子任务。

它有三条铁律：

1. 执行与评估分离：干活的 agent 不评判自己的进度，停滞判断由编排层基于量化指标做。
2. fresh session over resume：每次迭代开新会话，不沿用 resume。
3. 强制方向多样性：多个候选方向时，优先增加多样性，而不是把一个方向越挖越深。

这和很多人的直觉相反。我们总觉得对话越长，agent 越懂上下文。但手册的判断是：上下文累积本身就是认知循环的主要成因之一。

所以它把“记忆”从聊天记录里拿出来，放进结构化文件。每次迭代开一个新 session，只注入经过筛选的状态。这样 agent 不会背着上一轮失败路径继续走，也不会被漫长对话里的无关细节拖住。

第三层：状态落盘，日志分流

手册第 4 节把状态和日志分开：

state/
  task_spec.md
  progress.json
  findings.jsonl
  directions_tried.json

logs/
  work.jsonl
  orchestrator.jsonl
  heartbeat.jsonl

这套结构的关键不是文件名，而是边界：

• state/ 是下一轮会被读取和注入的结构化状态。
• logs/ 是事件流，主要供事后排查，不应该变成下一轮上下文。
• 关键决策写进 work.jsonl，并用 level=decision 标记。

这相当于把“agent 的记忆”从不可控的对话历史迁移到可审计、可裁剪、可重放的文件系统。

第四层：停滞要量化，改向要改结构

手册第 6 节用 stale_count 检测停滞，并且特别强调：反复停滞后要做结构性改向，而不是继续调战术参数。

这句话很像工程版的“别在错地图上跑得更快”。

当一个任务在同一框架内反复没有进展时，更用力通常没有意义。真正需要改的是：

• 可用工具
• 搜索空间
• 验证方式
• 子任务切分
• 输入材料
• 约束条件

手册还给单次工作会话设了硬上限：15 轮或 30 分钟，先到即止。这个上限不是为了省 token，而是防止 agent 在一个坏方向里把上下文、时间和状态一起污染。

值得注意的是，手册也诚实保留了一个内部不一致：第 5 节写 stale_count>=3 生成新方向，第 6 节表格写 stale_count>=2 触发结构性约束变化。译注没有擅自统一，而是标出冲突。这个处理本身就符合它的精神：协议必须可审计，连原文不一致也要暴露。

第五层：看门狗要独立于业务循环

最有工程味的是第 7 节：业务循环本身不可靠，所以要有独立的 heartbeat watchdog。

手册把看门狗分成三层：

• L0：常驻 shell guard，不依赖 session。
• L1：持久化 cron，定时巡检状态。
• L2：业务循环自己更新 last_seen。

设计目标是：任意一层死亡，都能被另一层发现并恢复。

这解决的是一个常见幻觉：我们以为“循环还在”就表示“任务还在前进”。但长程 agent 里，循环本身也是会坏的。它可能卡住、静默失效、被上下文压缩切断，甚至最后一句输出是问题，等着用户来救。

所以 watchdog 不关心 agent 自己怎么解释，它只看事实：进度多久没更新？最后输出是不是问题？轻推三次是否仍无进展？达到条件就重启或改向。

第六层：子代理不是越多越好，而是要有调度模式

第 8 节把 subagent 调度抽象成四种模式：

手册还规定了子代理提示词的五要素：

• 背景
• 可验证交付物
• 工作目录
• 文件 / 行数上限
• 完成判据

这五要素的意义，是让 subagent 不依赖主会话的“默契”。每个子代理都应当像拿到一张工单：知道自己在哪工作、交付什么、最多改到哪里、怎样算完成。

第七层：工程红线比提示词更可靠

第 9 节列了六条工程约束，其中几条非常适合直接借用：

• 每次迭代最多 5 个大文件，单文件不超过 300 行。
• 状态通过文件注入，而不是通过对话历史。
• 两次迭代之间必须跑测试、编译或检查。
• 类引用内容每 20 条核验一次，不能攒到最后。
• 多个候选方向时，优先增加多样性，而不是深挖单一路径。
• 无法解决的外部依赖失败必须升级：完整报告、通知 owner、轮询等待回复，不能静默放弃。

这些规则看似细碎，其实在限制 agent 的“破坏半径”。它们把不可控的长程任务切成可回滚、可检查、可交接的小段。

最重要的诚实：它不是魔法

第 10 节有一个很好的收尾：手册列出框架承载过的异构任务和论文产出，但也明确写了局限：

• 自评分只在同一协议内纵向可比，不是外部质量声明。
• 最长连续运行记录是 72 小时，中间仍保留方向性人类输入。
• 幻觉来自 LLM 本身，框架只能通过流程降低风险，不能消灭它。
• 职责分离依赖协议约束，不依赖模型自律；约束一撤，越界行为会复现。

我很喜欢这个边界感。它没有把 agent 包装成完全自主的“数字员工”，而是把它当成一个需要护栏、状态、监控、验收和升级机制的执行系统。

我从这份手册带走的三个原则

第一，长程 agent 的核心问题是系统问题，不是聊天技巧问题。
一次提示词能让 agent 走得更顺，但不能保证它 72 小时不失忆、不停滞、不自我循环。

第二，状态必须外置，验证必须机械化。
只要状态还依赖对话历史，长程任务就会被 context compaction 和上下文污染拖垮。只要验证还依赖 agent 自评，就会出现“看起来完成了”的假阳性。

第三，人类应该做方向性干预，不该做运行时救火。
如果系统每隔一会儿就要问人“下一步怎么办”，它就不是 autonomous workflow，而是一个被动助手。真正的目标是：日常提交、重试、修复、轻推、重启都自动化；只有结构性卡死、外部依赖失败、方向判断才升级给人。

结语

Deli AutoResearch 给我的启发是：未来好用的 agent 系统，不会只是一个更会写代码的模型，而会越来越像一个小型分布式系统。

它有状态文件，有日志，有 watchdog，有执行层和评估层，有子代理调度，有升级策略，也有明确的工程红线。

换句话说，agent 的能力来自模型，但 agent 的可靠性来自系统。

资料来源：本地文件 D:/2026ai/study/Deli_AutoResearch原文对照译注手册.html，原文权威来源见手册所列 D:/2026ai/study/.claude/skills/deli-auto-research/SKILL.md 与 victorchen96.github.io/auto_research/framework.html。