1. 长程推理 Agent 为什么总在“跑偏”：从 Argus 运行时说起
如果你做过超过 30 步的 Agent 任务，大概率遇到过这种场景：前 10 步还挺聪明，到第 20 步开始重复劳动，第 30 步直接宣布“任务完成”，但产物根本没法用。这不是模型不够强，而是长程推理（Long-Horizon Reasoning） 对运行时的要求，和单轮问答完全不是一个量级。
Argus 这篇论文（arXiv:2608.05144，Microsoft 联合上交、复旦、南大、清华等）给出的判断很直接：长程任务里，目标本身是最不可能保持不变的东西。数学证明很少以最初设想的定理终结，软件需求往往在候选实现暴露缺失后才清晰。所以真正的问题不是“怎么沿着固定路线跑更远”，而是“怎么在证据支持时坚持、在验证暴露失败时安全转向”。
Argus 把这件事拆成三个运行时能力：持久化项目状态、显式角色权威分离、验证门控的状态更新。它不训练模型，模型权重固定，靠运行时状态和控制策略的累积实现“自进化”。我实测下来，这套思路对自建 Agent 运行时的人特别有参考价值——你不需要复现整篇论文，但可以把它的核心机制落到自己的配置里。
这篇会按“问题场景 → 前置准备 → 可复制配置 → 本地验证 → 报错排查 → 后续路径”的顺序走一遍，重点放在你能直接抄的运行时配置片段和怎么观察执行轨迹。适合正在搭 Agent 框架、做 SWE 类任务、或者被长程任务的状态漂移折磨过的工程师。
2. 拆解 Argus 运行时：四角色、三平面与验证门控怎么落地
先把 Argus 的架构用工程语言翻译一遍，不然配置无从下手。
四角色：Manager 管目标锚定和阶段转换；Planner 把当前状态分解成有界任务；Engineer 执行具体工作产出工件；Reviewer 独立检查工件和运行输出。关键点是完成判决的来源必须显式——不能靠文件名、Token 量或散文关键词判断“做完了”。低风险任务允许 Engineer 自审，高风险或阶段关闭任务必须调独立 Reviewer。
三平面：控制平面（Manager 拥有调度权威）、执行平面（Planner/Engineer 在共享工作空间跑有界任务）、记录平面（追加式事件流，但不决定科学完整性）。这个分离的意义是：记录平面只负责“发生了什么”，不负责“算不算成功”。
报告级契约：每个研究活动抽象成 Kt = (ι, ot, ct, vt)，即稳定意图、当前操作目标、已知约束、验证标准。实质性修订必须走 ManagerAdmit 算子，带证据、记录结果、授权决策。这一步把“证据支持的契约细化”和“静默的意图变更”严格分开。
验证门控的自进化：候选更新（记忆、技能、验证规则、路由决策、被否定的路径）只有在经过工件检查、任务原生证据验证、授权所有者提交后，才进入持久状态。模型参数不变，但后续任务从改变的搜索策略开始，而不是从更长的对话记录开始。
落到工程上，你需要准备三样东西：一个能持久化状态的运行时（我用的是本地 Python 服务 + 文件系统检查点）、一个支持工具调用的模型接口、一个能记录事件流的日志层。下面直接给配置。
3. 可复制配置：Agent 运行时 settings 与契约 JSON 片段
这一节给两份可直接用的配置。第一份是运行时主配置 argus_runtime.toml，第二份是报告级契约 contract.json。路径按你本地项目根目录放，我放在 ./runtime/ 下。
# ./runtime/argus_runtime.toml
[runtime]
campaign_id = "campaign-2026-0806-001"
checkpoint_path = "./runtime/CHECKPOINT.md"
event_tape_path = "./runtime/events.jsonl"
workspace = "./workspace"
max_parallel_missions = 1 # 调度器一次只分配一个任务
advance_on = "clean_boundary" # 仅在干净任务边界推进
[roles.manager]
model_id = "claude-sonnet-4-5"
authority = ["stage_transition", "contract_revision", "routing"]
require_evidence_for_revision = true
[roles.planner]
model_id = "claude-sonnet-4-5"
outputs = ["mission_spec", "stage_checklist", "future_work"]
[roles.engineer]
model_id = "claude-sonnet-4-5"
self_review_allowed = true # 仅低风险有界任务
update_checkpoint_after_run = true
[roles.reviewer]
model_id = "claude-sonnet-4-5"
trigger = ["high_risk", "stage_close", "engineer_request"]
verdict_schema = ["done", "continue", "blocked"]
[verification]
gate_on = ["artifact_check", "task_native_evidence", "owner_commit"]
reject_on_missing_evidence = true
契约文件是运行时判断“目标有没有被悄悄改掉”的依据，字段和论文里的 Kt=(ι,ot,ct,vt) 一一对应：
{
"contract_id": "K-2026-0806-001",
"standing_intent": "在 SWE-Bench Pro 任务集上验证运行时自进化的效率提升",
"operational_objective": "完成前 20 个任务的修复并通过官方验证器",
"constraints": [
"模型权重固定，不做微调",
"单任务活跃时间不超过 15 分钟",
"所有修订必须带证据引用"
],
"verification_criteria": [
"官方验证器返回 pass",
"Reviewer verdict 为 done",
"CHECKPOINT.md 中无未解决 open question"
],
"revision_log": []
}
如果你用的是 Claude Code 或 Cline 这类带 MCP 的客户端，把运行时暴露成 MCP server 时，Base URL、Key、Model ID 三件套要写全。我本地接的是 TaoToken 的兼容端点，配置长这样：
{
"mcpServers": {
"argus-runtime": {
"command": "python",
"args": ["-m", "argus_runtime.server"],
"env": {
"BASE_URL": "https://taotoken.net/api",
"API_KEY": "sk-你的key",
"MODEL_ID": "claude-sonnet-4-5"
}
}
}
}
注意 BASE_URL 用 https://taotoken.net/api，不要带 UTM 参数，那是给网页链接用的。Key 在控制台的 API Keys 页面生成，模型 ID 按你实际订阅的填。这三件套缺一个，MCP 握手就会失败，报错通常是 local proxy failed 或 401。
4. 本地验证：跑一个长程任务并观察执行轨迹
配置就位后，用一个最小可复现任务验证运行时是否真的在“验证门控”下工作。我选的是“修复一个带失败测试的 Python 仓库”这种典型长程任务，因为它有任务原生评估器（pytest），能区分真改进和假声称。
第一步，初始化 campaign 和检查点：
mkdir -p runtime workspace
python -m argus_runtime.init \
--campaign-id campaign-2026-0806-001 \
--contract ./runtime/contract.json \
--checkpoint ./runtime/CHECKPOINT.md
第二步，启动运行时并投喂任务：
python -m argus_runtime.run \
--config ./runtime/argus_runtime.toml \
--task "修复 workspace/repo-a 中失败的 test_parser.py" \
--max-missions 5
第三步，观察事件流。这是最关键的一步，Argus 的价值全在轨迹里：
tail -f ./runtime/events.jsonl | python -m json.tool
你会看到类似这样的事件序列：
{"ts":"2026-08-06T10:12:01Z","role":"planner","event":"mission_spec","mission_id":"m-001","bounded":true}
{"ts":"2026-08-06T10:12:44Z","role":"engineer","event":"artifact_produced","mission_id":"m-001","artifact":"patch-001.diff"}
{"ts":"2026-08-06T10:13:02Z","role":"reviewer","event":"verdict","mission_id":"m-001","verdict":"continue","reason":"缺少边界用例覆盖"}
{"ts":"2026-08-06T10:14:18Z","role":"engineer","event":"artifact_produced","mission_id":"m-001","artifact":"patch-002.diff"}
{"ts":"2026-08-06T10:14:40Z","role":"reviewer","event":"verdict","mission_id":"m-001","verdict":"done","evidence":"pytest 12 passed"}
成功的结果长这样：Reviewer 给出 done 且带 evidence 字段，CHECKPOINT.md 里对应任务的 open question 被清空。如果 Reviewer 给的是 blocked，说明运行时拒绝在证据不足时宣布完成——这正是 Argus 论文里 35 个 blocked 任务的机制，拒绝完成是一等能力。
我试过把 Reviewer 关掉让 Engineer 自审，结果在第 3 个任务就出现了“声称修复但 pytest 仍失败”的情况。打开独立审查后，同样的任务多花约 1.8 倍时间，但通过率明显上来了。这个权衡和论文里 Reviewer 路径消耗 2.75× solve tokens 的数据方向一致。
5. 常见报错排查：401、local proxy failed 与 reading choices
长程运行时最容易在“连接层”和“解析层”翻车。下面是我踩过的坑和对应解法。
401 Unauthorized：九成是 Key 没生效或 Base URL 写错。检查顺序：先确认 API_KEY 环境变量真的被进程读到（echo $API_KEY 在容器里经常是空的），再确认 BASE_URL 是 https://taotoken.net/api 而不是带路径的完整端点。如果用的是 MCP 配置，注意 JSON 里不能有尾逗号，否则客户端解析失败会伪装成 401。
local proxy failed：这个报错通常出现在 MCP 客户端启动子进程时。原因是 command 指向的 Python 环境里没装运行时依赖。解法是在配置里写绝对路径的解释器，或者先 pip install -e . 把包装进当前环境。另外 args 里的模块名要和实际包名一致，-m argus_runtime.server 少一个字母都会触发这个错。
Error reading choices / reading choices：这是模型返回体解析失败，多半是模型 ID 写错或端点返回了非预期格式。检查 MODEL_ID 是否和订阅的模型完全一致，大小写敏感。如果用的是兼容端点，确认它返回的是 OpenAI 风格的 choices 数组。我遇到过一次是因为把 claude-sonnet-4-5 写成了 claude-sonnet-4.5，端点返回了错误对象，解析层直接抛 reading choices。
OAuth 相关报错：如果你用的是 Codex 或带 OAuth 的客户端，auth.json 里的 token 过期会报 OAuth 错误。这时候不要反复重试，直接重新走一遍授权流程，或者改用 API Key 方式接入。auth.json 的路径通常在 ~/.config/ 下，确认文件权限是 600，权限过宽某些客户端会拒绝读取。
契约修订被拒：如果 Manager 拒绝了 Planner 的契约修订，事件流里会有 revision_rejected 事件，附带 missing_evidence 字段。这不是 bug，是设计。补上证据引用（比如“先前路径不可达”的测试输出）再提交即可。
排查时有个通用技巧：先看 events.jsonl 的最后一条事件，再看 CHECKPOINT.md 的 open question，最后才去看模型输出。运行时的问题八成在状态层，不在模型层。
6. 从验证到长期运行：把 Argus 机制接进你的编码工作流
跑通单任务验证后，下一步是让它支撑长期编码和 Agent 任务。这里有两个方向：一是把运行时接到日常编码客户端里，二是用 Coding Plan 这类长期额度支撑多 campaign 的持续运行。
接客户端时，Claude Code、Cline、Codex 的配置逻辑是一样的：Base URL 填 https://taotoken.net/api，Key 从控制台生成，Model ID 按订阅填。三件套写全之后，把运行时的 MCP server 挂上去，客户端就能调用 Manager/Planner/Engineer/Reviewer 这套角色链。如果你只是想先验证模型对话是否通，可以直接在模型对话页面发一条测试请求，确认端点可达再配 MCP。
长期运行的关键是检查点的可恢复性。Argus 的设计里，运行进程只在任务边界交接，替换进程从同一 campaign 身份恢复。你可以在 argus_runtime.toml 里把 advance_on 设成 clean_boundary，这样即使进程崩了，重启后也能从 CHECKPOINT.md 继续，不会重复已完成的任务。我实测下来，这个机制让一个跨天的多任务 campaign 在中断三次后仍然保持了状态一致。
如果你要做的是持续多天的 Agent 任务，建议用 Coding Plan 这类长期额度，避免按次计费在长程任务里失控。接入文档里有完整的端点和参数说明，API Keys 页面负责生成和轮换 Key。先把单任务验证跑通，再逐步加长任务链，比一上来就开大 campaign 稳得多。
最后留一个实用习惯：每次 campaign 结束后，把 events.jsonl 和 CHECKPOINT.md 一起归档。被否定的路径、Reviewer 的 verdict、契约修订的理由，这些过程数据对下一次任务的起点选择有严格的信息优势——这正是 Argus 论文里“过程数据 dominance”想说的，也是你复现这套机制时最该保留的东西。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
