agent 自动化最大的敌人，是它死得悄无声息

前几天刷到 Anthropic 官方博客的一篇工程笔记，讲的是他们内部天天在用的一个东西。

定时跑的 agent 自动化。

每个工作日早上，一个 agent 自动醒来，去读指定的 Slack 频道和 GitHub 仓库，看看上次运行之后又发生了什么，然后把今天真正需要知道的几件事写成一份简报，发回 Slack。他们管这个叫 daily brief。

听起来很简单，cron 加一个 LLM，半天就能糊一个出来。

但文章里有个判断我觉得说到了根子上。这种自动化最难的从来不是搭建，是它可能在你毫无察觉的情况下悄悄坏掉。某个数据源的 token 过期了，没人知道。agent 读不到东西，它不会报警。

它会告诉你，今天没什么新消息。

一个不吭声的故障，比一千次报错更可怕。

他们基于 Claude Managed Agents（beta）把这套东西做成了开源的参考实现，配置全部公开，还附了一条可以在 Claude Code 里直接跑的命令，让 agent 自己帮你把自动化配好。

我把整篇文章读了两遍。最值得抄的不是代码，是那些踩过坑才知道的 failure modes。按它的六个组件，一块一块拆开讲。

系统全貌。定时器唤醒 agent，agent 从来源读、往记忆里读写、确认没发过之后把简报投到唯一的目的地，全程罩着护栏（图源 Anthropic 官方博客，下同）

01

来源，凭证别进沙箱，失败别装平静

先说凭证。

这套实现里，agent 的凭证全部放在 vault 里。沙箱中的 agent 只能拿到一个占位符，比如 $SLACK_BOT_TOKEN。请求离开沙箱的那一刻，平台才把真 token 换进去，而且只对你白名单里的域名生效。GitHub 那边走 MCP，代理跑在沙箱外面。

意思是，就算 agent 被谁骗了，它也摸不到真凭证。

第一个坑，固定时间窗口。

很多人写这种 agent，张口就是「读最近 24 小时」。晚跑一次就漏一段，早跑一次就重复一片。

他们的解法是给每个源一个书签。每次运行结束，agent 把这次读到最新一条的时间戳写进 bookmarks.json，下次从这里接着读。窗口自动伸缩，刚好盖住两次运行之间的空隙，一条不重复，一条不遗漏。

第二个坑，也是我觉得全文最值得划线的地方。

如果 MCP 服务器挂了或者 token 过期，这次运行照样开始，只是那个源的工具没了。日志里会记一个错误，但 agent 自己感知不到。它看到的是那个源安安静静，于是如实汇报，没有新消息。

一个不吭声的故障，伪装成了平静的一天。

agent.md 里写了三条规则对付它。读失败的源，书签原地不动，下次补读。简报用其他正常的源照写。最后，简报末尾必须留一行，明说这次什么没读到，比如「本次未能读取 pull requests」。

让读者知道简报有缺口，比假装完整重要得多。

来源这一层。凭证从 vault 出，对源只读

02

目的地，确认落地了再记账

简报只往一个地方发，一个 Slack 频道，一天一条。

发这个动作本身只要一条 curl，真正的学问在确认。

如果 agent 记了一笔「已发送」，而那条消息其实没发出去，书签就会往前走，那些条目从此消失，永远不会再被报告。反过来，如果它不确定发没发成又补一条，读者就收到两份一样的简报。

所以它有三条规矩。发之前，先在频道最近的消息里找今天的标题，已经存在就不再发。Slack 接口返回 ok true 并且带回消息 ts，这次发送才算数。确认落地之后，才去更新台账和书签。

如果结果说不清，运行记录里标一个 maybe posted，别的什么都不改。

宁可留一个悬念，不能丢一条消息。

目的地这一层。一个工具，一个地方，预先批准

03

Agent 本体，简报要短，发之前再查一遍

在 Managed Agents 里，agent 就是一份版本化的配置。模型、system prompt、工具，全在 agent.md 一个文件里。

因为没人盯着它跑，MCP 工具默认要人工批准这一点必须放开，GitHub 工具集设成 always_allow，对应的 token 只读。权限放开和权限收紧，在这里是同一枚硬币的两面。

这份配置里有两段指令我觉得写得很漂亮。

一段管简报的长度。判断标准只有一条，读者今天会照着它行动吗，它会改变读者即将做的某个决定吗。拿不准就不写。「12 个待评审的 PR」不算一条消息，哪个被卡住了、把链接放出来，才算。已经在台账里且还没解决的事，标一句「仍在等，第 3 天」带过，不重复报告。

另一段管发送前的复核。世界在你读源的时候还在动。每一条要写进简报的事，发送前重新去它的源头查一次活着的状态。已经解决了，删掉。还在等但情况变了，改写法。确认不了，也删掉，记进运行记录的删减清单。

原文有一句话值得抄下来。一条过期的「还在等你」，比漏掉十条消息更伤信任。所以永远不要对一条目的状态含糊其辞，要么断言，要么删掉。

还有一条细节，所有链接必须从源自己的字段里复制，PR 的 html_url、Slack 的 permalink，绝不手写拼接。手拼的链接，是 agent 简报里最常见的假消息来源。

Agent 这一层。模型加提示词，运行循环和判断规则都在这

04

定时，先把时区说明白

agent 只是一份配置文件，真正让它跑起来的是 deployment。定时表达式、时区、每次运行的第一条消息、vault、记忆库、预算，全在这一个文件里。到点，平台起一个全新的会话，跑完即停。

这里有个特别朴素的 bug，几乎每个写过定时 agent 的人都踩过。agent 把「今天早上」算成了「昨天」，因为它按服务器的时区算日期。

解法也朴素。deployment 里写死 timezone 字段，再在每次运行的第一条消息里明说一句，读者的时区是这个，所有日期按它算。

工程里没有小问题，只有没被说出口的前提。

定时这一层。deployment 负责唤醒，agent 自己不记住时间

05

记忆，两个库，一本台账

每次运行都是全新沙箱，上一次的事它一点都不记得。没有记忆，你给的反馈永远不生效。可记忆一旦过期，危害更大，它会把已经解决的事说成还在等，或者把还开着的事当成「已经报过了」直接丢掉。

这套实现拆了两个记忆库。

preferences 是你的，对 agent 只读。读哪些频道和仓库、什么不要、长度上限、发到哪、什么时候该停，都在里面。

state 是 agent 自己的，可读写。书签、报过什么的台账、每次运行的记录、它想对你偏好提的修改建议，还有它给每个源记的脾气笔记，比如「这个源只返回最新 50 条」。

使用纪律有两条。

preferences 每次运行开头重新读一遍，绝不把副本烤进 prompt，不然你改了规则它还在执行旧的。读不到就停下来明说，而不是揣着默认值硬跑。

state 里那本金句台账 ledger.md，每条报过的消息一行，带一个不会变的 ID 和最后已知状态。还在等的标一句「第 3 天，仍在等」，不重复报告。已经关闭的，默默拿掉，不解释。

记忆这一层。preferences 只读，state 可写，分工明确

06

护栏，按「被注入了也不能怎样」来设计

最后说护栏。自动化是在后台没人盯着跑的，所以必须限制两件事，它能做什么，它能花多少。

能做什么。agent 读的是别人写的消息和 issue，而那些文字是可以伪装成指令的。所以整套系统按最坏的打算设计。GitHub token 只读，preferences 只读，沙箱网络只通白名单上的几个域名。就算真有人往频道里埋了一句恶意指令，最坏的结果也就是简报里被带偏一句话，伤不到仓库和系统。

能花多少。deployment 里挂着每次运行的花费上限。定时任务最怕的不是一次跑飞，是每天跑飞一点点，月底账单才发现。

护栏这一层。轮次、时间、花费都有上限

回头看这六块，你会发现一件挺微妙的事。

这套方案里没有一处是在教模型变聪明。书签、台账、发送前复核、maybe posted、只读凭证，每一条都在做同一件事。

信任不是模型给的，是工程挣回来的。

我们讨论 agent 的时候，注意力大多还在模型能力上，谁的分高，谁会上网，谁会写代码。但这篇文章提醒我，真正把 agent 用进日常工作的团队，操心的是另一层的问题。它会不会安静地坏掉，它说的话我敢不敢不复核就信。

模型决定 agent 能做什么。这些不起眼的工程细节，决定你敢不敢让它天天做。

最后把资源放这。参考实现开源在 GitHub，anthropics/claude-quickstarts 仓库的 managed-agents/daily-brief 目录。想交互式走一遍配置流程，在 Claude Code 里跑这条命令就行。

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

原文 Building effective agent automations，作者 Lance Martin 和 CJ Avilla，2026 年 10 月 8 日发布于 Anthropic 官方博客。