Agent Automation

Agent Automation 指无人值守、按调度定时运行的后台 Agent 自动化：没有人发消息触发它，而是由 cron 之类的调度周期性唤醒，从一组固定来源（Slack 频道、GitHub 仓库等）读取自上次运行以来的变化，把"你需要知道的事"投递到一个目的地（如一个 Slack 频道）。这个词主要来自 Anthropic 的工程语境（其文章《Building Effective Agent Automations》与 Claude Managed Agents 的生产参考实现），尚不算完全标准化的行业术语，但对应的实践形态——定时摘要、巡检通知、后台值守——已经在各家托管 Agent 平台普遍出现（参见 Agents API）。

与交互式 Agent 相比，它的根本差异是没人盯着：MCP 工具要权限审批时没人批，来源挂了没人发现，post 失败没人重试，成本失控没人喊停。所以它的工程重点不在模型能力，而在把"读增量、报失败、确认送达、管住花钱"做成确定性规则写进 run steps。

从 Prompt 到全托管部署的演进（Claude Managed Agents）

在 Anthropic 提供的 Claude Managed Agents（全托管 Agent 平台）出现前，开发无人值守自动化通常经历一个脆弱的本地原型期：开发者把指令写成 Skill、依靠本地机器的计划任务唤醒、并将记忆保存在本地文件夹中。生产级基础设施为这一演进提供了标准化的托管抽象：

flowchart LR
    subgraph S1["第一阶段：Prompt 提示词"]
        direction TB
        P1["单次任务交给 Claude"] --> P2["修正错误与偏差"] --> P3["积累保存纠偏记录"]
    end

    subgraph S2["第二阶段：Prototype 本地原型"]
        direction TB
        T1["单一职责 Skill"] --> T2["本地 Scheduled Task"] --> T3["本地共享文件夹知识库"]
    end

    subgraph S3["第三阶段：Deploy 托管部署"]
        direction TB
        D1["Agent System Prompt
（版本化指令）"]
        D2["Deployment Schedule
（云端常驻调度）"]
        D3["Memory Store
（云端持久共享记忆）"]
    end

    S1 --> S2 --> S3

在迁移到托管基础设施后，原先零散的本地构件被形式化为受控的云端资源：

原型构件（本地 Claude）	托管构件（Claude Managed Agents）	生产环境收益（Gained）
单任务 Skill	Agent System Prompt	版本化隔离（Versions）：指令每次更新产生新版本，已部署实例固定运行已验证版本，避免调试影响生产
本地计划任务（cron）	部署绑定的 Schedule	脱机自主执行（Background Run）：在云端按时区与周期静默触发，本地电脑离线或关机完全不影响运行
本地共享文件夹	云端 Memory Store	多 Agent 共享持久记忆：读写权限受控，任一 Agent 沉淀的教训全队立即可见
环境变量 / 本地密钥	Credential Vault	凭证隔离与最小权限：外部服务令牌留在沙箱外，模型运行可见能力但永不可见明文密钥
终端滚动日志	Console Run Traces	步进链路追踪（Run Traces）：完整回放每轮工具调用、中间思考与状态迁移

个人跨账户代办：Claude Duet

Claude Duet 将后台 Agent 带到个人连接的应用与服务：关闭客户端后仍可读收件箱、起草回复、预订事项和运行例行任务。它不是单一 cron 摘要的同义词，也不意味着把所有任务的写权限提前授予 Agent。根据其安全说明，后台任务仍须遵循与交互任务相同的敏感动作审批、独立意图检查和敏感信息检查；付款等步骤不能设置“不再询问”。

这给无人值守设计补了一个边界：后台持续执行不等于持续无条件执行。系统可以自动推进低风险步骤，在需要批准时保留任务并交还用户；来源断连则停止新访问，但不会自动删除从来源形成的长期记忆，须单独提供重置入口。其托管凭证采用工作机器内占位符、机器外代理注入真值的方式，与 Managed Agents 的隔离方向一致。

六个基础组件

Anthropic 的参考实现把一个定时自动化拆成六个组件：

组件	内容	关键设计
Sources	命名的读取来源列表	只读；经 MCP 代理或 HTTPS 访问，凭证放 vault 不进沙箱
Destination	唯一可写的投递目的地	一个 Slack 频道；投递成功前不改任何状态
Agent	模型 + 系统 prompt + 工具的版本化配置	`agent.md` 里写 run steps 和判断规则
Schedule	cron 调度	`deployment.md` 声明调度、时区与每轮首条消息
Memory	preferences（用户只读）+ state（Agent 读写）	书签、账本、运行记录都在 state
Guardrails	能做什么、能花多少	只读权限、网络 allowlist、每轮预算上限

flowchart LR
    S["Schedule（cron）"] --> A["Agent（沙箱内运行）"]
    A -->|"读增量（书签→本轮窗口）"| SRC["Sources
Slack / GitHub 等"]
    A -->|"确认送达后投递"| D["Destination
Slack 频道"]
    MEM["Memory
preferences（只读）+ state（读写）"] <--> A
    G["Guardrails
只读权限 · allowlist · 预算"] -.->|约束| A

在 Claude Managed Agents 上，Agent 只是配置文件（agent.md、deployment.md、environment.yaml、记忆 store 与 vault 的 YAML），ant apply 命令把资源创建到平台侧，之后调度运行完全在 Anthropic 基础设施上，本地不需要任何常驻进程。每轮调度触发都会开一个全新 session、全新沙箱。

增量读取：书签，不是固定时间窗口

最常见的错误是让 Agent 读"最近 24 小时"：跑晚了留缺口，跑早了重复报。正确做法是给每个来源维护一个书签（bookmark）——每轮结束时把该来源读到的最新条目时间戳写进 bookmarks.json，下一轮从书签开始读。窗口随两次运行的实际间隔伸缩，天然覆盖"跑晚了的缺口"，也不重复。

失败的读取 ≠ 安静的一天

如果某来源的 MCP server 挂了或 token 过期，run 仍会启动，只是缺那一路工具——Agent 什么都看不到，于是报"今天没新东西"。读者会误以为真的无事发生。规则是：来源读取失败时，书签保持不动（下次接着读）、用其余来源照常出报、并在结尾明确写一行"本次无法读取 XXX"。宁可承认读不到，不能把故障伪装成无事。

投递确认：先确认，后记账

自动化有真实副作用（往频道发消息），持久执行原则在这里体现为记账必须晚于确认：如果记了账但消息没发出去，书签已经前移，那些条目永远不会再报；如果不确定是否发出就再发一次，读者收到重复报。daily-brief 的做法分三步：

发帖前先在频道近期消息里查今天的标题，已存在则不重发（幂等去重）；
只有 Slack 返回 "ok": true 且带 message ts 才算发送成功；
确认之后才更新账本和书签；结果不明就把本轮标记为 “maybe posted”，其余一律不动。

Agent 记忆里维护一份账本（ledger）：每条报过的条目记录报告日期、来源、不变 ID（Slack 消息时间戳 / PR 号）和最后已知状态。已报且仍开放的条目只折叠成一行"仍在等，第 3 天"，不重复展开；已关闭的静默移除。

发布前复核：世界在你读取时继续动

从读取来源到发帖之间有时间差，条目可能已经解决或状态反转。规则是在发帖前对每条要报的条目重查实时状态：已解决则删掉，仍开放但变化则改写，无法确认则删掉并记入本轮 cuts。文中给出的判断值得记住：一条过时的"还在等你处理"比十条漏报更伤信任，所以状态要么断言、要么删掉，绝不模糊措辞。所有链接都从来源自身的 link 字段复制（如 PR 的 html_url），不手工拼。

记忆双仓：偏好只读，状态读写

无人值守场景下记忆要分两仓：

preferences（用户的，Agent 只读）：读哪些频道和仓库、排除什么、长度上限、投递目的地、何时停止。每轮开始重新读文件，绝不把偏好复制进 prompt——prompt 里烤进去的副本会在你改完偏好后继续生效旧规则。读不到偏好文件时应停下来报告，而不是按默认值跑。
state（Agent 的，读写）：书签、账本、每轮运行记录、对偏好的修改建议、各来源的行为笔记（如"只返回最新 50 条"）。

陈旧记忆同样危险：会把已解决的报成"仍在等"，或因"已报过"而漏掉仍开放的事。

护栏：没人盯着的自动化要限权限钱

定时自动化的护栏有两类：

限制能做什么。 Agent 读的消息和 issue 是别人写的文本，可能被解读成指令（提示注入，见 OWASP Agentic AI Top 10）。原则是：只读的地方就给只读权限——GitHub token 设 read-only、preferences store 对 Agent 只读、环境只放行 allowlist 内的主机。同一 token 读写共用时（如 Slack bot），只把 bot 拉进它确实需要读写的频道。

限制能花多少。 每轮运行设预算上限（Managed Agents 的 budget），从真实运行成本出发：初始设为正常一轮的 3–5 倍，看到真实数字后再收紧。触顶的 run 是暂停而非失败（stop reason 为 budget_reached）——所以预算设太低的表现不是报错，而是简报悄悄消失。架构图里还有一点正文未展开但值得记下：护栏还包括轮数/时间上限，以及一个有人盯着的 heartbeat——后台自动化需要外部的心跳监控，沉默本身就应该触发告警。

舰队化演进：单职责协作与共享记忆（The Nakama 模式）

单体自动化（如一个日更 daily-brief）往往随着业务复杂度增加而变得脆弱。Anthropic 在日本团队业务自动化中的实践表明，生产级自动化正在演变为单职责 Agent 舰队（Single-responsibility Agent Fleet）：

flowchart TB
    subgraph Inputs["多源业务输入"]
        IN_LEAD["线索队列"]
        IN_GMAIL["Gmail 收件箱"]
        IN_CAL["会议转写纪要"]
        IN_CRM["Salesforce CRM"]
    end

    subgraph Coord["运维中枢"]
        COORDINATOR["Coordinator（Opus）
监控 Slack，依自然语言指令更新各 Agent 指令与记忆"]
    end

    subgraph Fleet["工作 Agent 舰队（Single Responsibility）"]
        direction LR
        AG_FURIWAKE["Furiwake 振分（Sonnet）
早间线索路由与负载均衡"]
        AG_SABAKI["Sabaki 捌き（Opus）
线索准入初筛与首封触达起草"]
        AG_HENJI["Henji 返事（Sonnet + Advisor）
每小时扫描收件箱起草回复"]
        AG_SHOUDAN["Shoudan 商谈（Sonnet）
依据交互自动同步 CRM 商机"]
        AG_NOKORI["Nokori 残り（Opus）
日终总结会议纪要并起草跟进"]
    end

    subgraph Memory["共享记忆层"]
        KB[("Shared Knowledge Base
（全员读写的 Memory Store）")]
    end

    subgraph Outputs["交付与协同"]
        direction TB
        OUT_SLACK["Slack 汇报频道"]
        OUT_DRAFTS["Gmail 草稿箱（供人核对发出）"]
        OUT_CRM["Salesforce 记录更新"]
        OUT_TAG["Slack @Claude
（承接非常规跟进）"]
    end

    Inputs --> Fleet
    Coord -->|"编译更新"| Fleet
    Coord -->|"更新知识"| KB
    Fleet <-->|"读写经验与偏好"| KB
    Fleet --> Outputs
    OUT_SLACK -.->|"抛出 [action-needed]"| OUT_TAG

舰队四大架构机制

职责解耦与模型分层：
- 规则清晰的确定性任务（Furiwake 路由、Shoudan CRM 记录）采用轻量模型（Sonnet）以提高吞吐；
- 复杂语境与长上下文任务（Sabaki 首触达、Nokori 会议善后、Coordinator 协调中枢）采用旗舰模型（Opus）；
- 高频触发的回复任务（Henji）采用 Advisor Pattern（顾问模式）：Sonnet 主导端到端循环，遇到疑难决策点主动向 Opus Advisor 咨询执行计划或纠偏指令，兼顾高频运行成本与极端质量。
全员共享记忆（Shared Memory Store）：
- 记忆仓独立于单次会话生命周期。工作 Agent 生成草稿后由人类审查发送，系统比对草稿与人类最终修改的文本差异（Diff），将措辞风格偏好存入记忆仓；
- 舰队内其他 Agent 在后续运行时自动吸纳该偏好，“一处修正，全队生效”。
人机协同速览（Summary for User）：
- 为避免人类逐字研读上下文长邮件，Agent 在邮件草稿顶部注入非发送的结构化摘要块：交代客户诉求、决策倾向（如因合规要求倾向 Enterprise 方案）、刻意留白（“Prices left out on purpose”）及知识库出处，使人类在几十秒内完成校验。
例行与异常分流：
- 例行事务在后台静默完成；
- 遇到合同变更、特殊对公发票结算等超出规则的非常规需求（out-of-routine），Agent 抛出动作项交接给工作区协同成员（在 Slack 中呼叫 @Claude，详见 Human-Agent Teams）进行跨部门工单推进与异步自提醒跟进。