1. Weekly Update – October 5, 2026

推荐理由： 这篇看起来只是一次 release update，但里面已经出现了一套很完整的“长期运行 Agent workflow”基础设施：work queue 负责待办状态，ledger 负责持久化结构化状态，safe outputs 控制写操作，audit artifact 记录轨迹和安全判断，tool-call budget 则限制执行成本。它很接近 software factory 的 runtime/control-plane 形态。

核心要点：

  • v0.90.3 新增 Git-backed work queue，以及 log / set / map / table / counter 等内置 ledger；队列还能使用 issue-backed storage，并把待处理工作分发给受信 worker workflow。Agent workflow 因此不再只能依赖一次运行中的 transient context，而开始拥有可恢复、可查询的持久状态。
  • 安全边界继续前移：safe outputs 对可写操作设置单次调用和标签数量限制，GitHub App token 在 compile time 就必须显式声明 scope，Claude 默认使用 strict MCP 配置；v0.90.1 还增加 ledger transaction 与 threat-detection 的 audit artifacts。
  • 系统开始显式管理自治成本与可靠性：支持 task-level model routing、run-wide tool-call budget，并新增 trajectory graders；同一套 daily-arxiv-researcher 在切换 Agent engine 后，单次读取 token 从约 7K/13K 上升到约 84K，也说明 autonomous workflow 需要把“完成任务”与“消耗多少资源”一起观测。

核心启示：真正可持续的 Agent workflow 不是一个 prompt 加 cron，而是 queue + durable state + constrained writes + audit + budget + grader。这些控制面能力决定了 Agent 能否从一次性 automation 变成长期运行的软件系统。

2. The Agent Said It Was Done. The Database Disagreed.

推荐理由： ThinkingBox 把 Agent eval 从“回答看起来对不对、tool call 是否成功”推进到真正的 outcome verification：任务结束后检查数据库最终状态、副作用和必要的用户回复，再把同一个任务重复执行 20 次。对于未来处理工单、订单、权限、部署和生产运维的 Agent，这种 verifier 比单次 benchmark 分数更接近真实可靠性。

核心要点：

  • ThinkingBox-Bench 包含 507 个 stateful business workflows，覆盖零售、电商、旅行、车险、neobank IT 和咨询 IT/HR；每次运行都从独立的 MCP session 和干净 backend state 开始，结束后用 executable checks 判断最终状态，而不是只看 Agent 的轨迹。
  • “tool 调用了”并不等于“任务完成了”。在覆盖 12 个模型的 121,680 次有效运行中，有 79,853 次没有通过最终检查；其中 67.24% 仍然正常结束、执行过状态修改，也没有最终 tool error。大量失败来自错误字段、额外副作用或遗漏动作。
  • 单次能力和稳定可靠性差异很大：benchmark 同时报告 pass@1、20 次中至少成功一次，以及 observed 20/20。Claude Opus 5.5 的 pass@1 为 67.16%，但只有 241/507（47.53%） 的任务能连续 20 次全部成功；这说明生产 Agent 的指标应该从“can do”转向“can repeatedly leave the system in the correct state”。

核心启示：Agent eval 的最终对象应该是 world state，而不是 transcript。Software factory 中每个自治步骤都应尽可能有 executable verifier，并把重复成功率、错误副作用和 cost per dependable task 作为一等指标。