Agent 运行 7 天必还的 5 笔运维债
## 运维债 1：权限矩阵——Agent 该能做什么，你可能没认真想过
Agent上线前，大多数团队做权限设计的方式，其实更像是“权限发放”。两者的区别在哪里？
- **权限发放**：把所有Agent可能用到的权限一股脑全给，然后祈祷它别出乱子。
- **权限设计**：只给Agent在正常流程中必须用到的权限，并且明确界定它绝对不应该做什么。
我们在第6天的时候，花了一个小时做了一张权限矩阵。但神奇的是，之前整整五天，没人做这件事——每个人都以为别人在管。
我们用的模板长这样：
```
## Agent 权限矩阵模板（填 //）
| 操作 | 是否允许 | 是否需要审批 | 每日上限 | 备注 |
|---|---|---|---|---|
| 读取数据 | | | 无限制 | 只读操作，无风险 |
| 生成草稿 | | | 20 篇/天 | 草稿不发布，不对外可见 |
| 发布内容 | | | 5 篇/天 | cooldown 30min |
| 修改已发布内容 | | | 5 次/天 | 需要 Telegram 确认 |
| 删除内容 | | — | 0 | 永不允许，只能由人操作 |
| 调用外部 Webhook | | | 10 次/天 | 需记录 payload |
| 修改系统配置 | | — | 0 | 高风险，禁止 |
| 发送通知/邮件 | | | 50 条/天 | 仅内部通知渠道 |
```
填表时冒出来的几个发现，让我们意识到之前的想法有多粗心。
**Agent 能修改系统配置。** 我们的Agent有调用内部API的权限，里面一个接口可以修改推送策略。当时给权限是因为“有时候需要动态调整”——但我们从来没认真想过，“谁来决定什么时候需要动态调整”。
**Agent 能调用外部 Webhook。** 理由也很充分，“有时候需要触发下游任务”。但Webhook几乎是不可逆操作——发出去就发出去了，没有撤回键。
等真把矩阵填完，“删除”和“修改配置”两列全部打上了叉。原因很简单：当你坐下来认真思考“如果Agent今晚出bug，误触发了这个操作，我能接受吗”，答案不言而喻。**没有任何Agent需要以自动化的方式去执行删除操作。** 如果它真的需要，那说明是流程设计出了问题，而不是权限的问题。
这张矩阵本身不是一段代码，它是一个团队共识。它的真正价值，是让团队里所有人对“Agent到底拥有哪些权力”有一个统一、清晰的认知，而不是各自凭感觉揣测。
## 运维债 2：失败恢复——“重试 3 次”不是失败处理，是鸵鸟
Agent的失败可以分成两大类，处理方式完全不同。把它们混在一起处理，是最常见的错误，也是最危险的。
**第一类：瞬时失败**
网络超时、遇到限流429、某个临时服务不可用。这类失败是可重试的，用指数退避策略处理就够了。
**第二类：结构性失败**
- 内容违规被平台拒绝——这种情况重试100次结果都一样。
- 操作已经成功执行了，但状态没记录上——重试会产生副作用。
- 认证过期——重试只会连续返回401。
- Agent的逻辑本身进入了死循环。
把这两类失败都丢给“重试3次”去处理，会是什么结果？我们第4天就领教过了：一个内容审核失败的任务被重试了5次，每次都向平台发出了相同的内容，结果被判定为刷量。
后来我们写了一个简单的失败分类器：
```python
# failure_classifier.py
from enum import Enum
class FailureType(Enum):
TRANSIENT = "transient" # 可重试
STRUCTURAL = "structural" # 不可重试，需人工介入
SIDE_EFFECT = "side_effect" # 操作可能已成功，幂等检查后再决定
def classify_failure(error_code: int, error_msg: str, attempts: int) -> FailureType:
# 认证/授权失败 → 结构性，别重试
if error_code in (401, 403):
return FailureType.STRUCTURAL
# 内容审核/业务逻辑拒绝 → 结构性
if error_code in (422, 451) or "content_policy" in error_msg:
return FailureType.STRUCTURAL
# 已执行但未确认 → 先查幂等再决定
if error_code == 0 and "timeout" in error_msg:
return FailureType.SIDE_EFFECT
# 限流/服务不可用 → 可重试，读 Retry-After
if error_code in (429, 503):
return FailureType.TRANSIENT
# 超过重试次数 → 升级为结构性
if attempts >= 3:
return FailureType.STRUCTURAL
return FailureType.TRANSIENT
# 在 task runner 里使用
async def handle_failure(task, error_code, error_msg):
failure_type = classify_failure(error_code, error_msg, task.attempts)
if failure_type == FailureType.TRANSIENT:
delay = 2 ** task.attempts * 60 # 2m, 4m, 8m
await queue.retry_after(task, delay_seconds=delay)
elif failure_type == FailureType.SIDE_EFFECT:
# 先检查操作是否已在目标侧生效
already_done = await check_idempotency(task)
if already_done:
await queue.complete(task) # 标记为完成，不重试
else:
await queue.retry_after(task, delay_seconds=60)
elif failure_type == FailureType.STRUCTURAL:
await queue.fail_permanently(task)
await notify_on_call(f"Task {task.id} hit structural failure: {error_msg}")
```
这段代码不长，但它清晰地划出了一条线：哪些失败是“应该重试”的，哪些是“不应该重试”的。这个区分，本该在Agent系统设计第一天就做好，而不是等到出了事故才来补。
还有一个反直觉的发现：**“操作已成功但状态没记录”这类失败，比显式错误更危险。**
显式错误，比如`422 Content Rejected`，你一眼就能看到。但Agent发出请求后，服务端已经执行了，可响应在网络传输中丢失了——这种情况，Agent以为操作失败了，就会重试，而目标侧实际上已经执行了两次。解决方案是Outbox Pattern：先写一条“我要做X”，等执行完再写一条“X已完成”，这两步写到不同的存储上。进程重启后，先查Outbox看看有哪些没确认。这块在上篇文章（Agent 跑 24 小时后，我补上的 6 个运维护栏）里有完整实现，这里就不重复了。
## 运维债 3：人工接管机制——“暂停”不等于“关掉”
这笔债我们欠得最晚，但代价也最直接。
第5天凌晨，Agent在执行一个批量任务时，行为开始出现异常——不是报错，而是开始生成质量极差的内容。后来确认是context window溢出了，导致了上下文丢失。当时我们的第一反应是“暂停”它，结果发现根本没有暂停的入口，只能`kill`。
`kill`掉进程，会带来三个问题：
1. 丢失所有正在进行任务的状态，重启后可能会重跑。
2. 不知道Agent当前到底做到哪一步了。
3. 重启后，Agent从头开始，之前那个错误的上下文状态（比如错误的context）依然存在。
我们后来实现了一个轻量的分级接管协议，核心就是4个端点：
```bash
# Level 1 - 软暂停：完成当前任务后不接新任务
curl -X POST \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-d '{"reason": "人工检查", "operator": "ethan"}'
# Level 2 - 检查点停止：跑完当前步骤就停
curl -X POST \
# Level 3 - 状态快照后立即停止
curl -X POST \
-d '{"sa ve_context": true}'
# 恢复（Level 1/2/3 均通用）
curl -X POST \
-d '{"operator": "ethan"}'
```
这四个端点，对应的是一个核心状态机：
```sql
RUNNING ──pause──→ PAUSING ──task_done──→ PAUSED
│ │
├──freeze──→ FROZEN resume│
│ │
└──terminate──→ TERMINATED RUNNING ←─┘
```
这套协议的关键点不在于技术细节有多复杂，而在于一件事：**让“暂停”成为Agent的内置行为**，而不是外部的强杀。Agent代码里每完成一个步骤，都会检查一次控制状态。如果状态是`PAUSING`，就不取下一个任务；如果是`FROZEN`，就立刻保存状态并退出。
有了这套机制之后，我们后来遇到的2次异常情况，都在2分钟内完成了接管，没有造成额外的状态损坏。
## 运维债 4：记忆污染——长跑 Agent 的 context 会越跑越“脏”
这是最难察觉的一笔债。
Agent第一次运行时，它的上下文是干净纯粹的——只有任务指令和当次的工具返回结果。但随着任务轮次不断累积，很多团队的Agent会习惯性地把历史任务的摘要追加进context（为了让Agent“记住”之前做过什么）。
短期内看，这确实很有用——比如Agent知道了“今天已经发了3篇文章”，就不会重复发。但有一个问题，几乎没有人会在设计阶段考虑到：**追加进去的历史摘要本身，可能是错的。**
如果某次任务失败了，失败的部分结果也可能被摘录进了context。等下一次任务开始时，Agent的“起始认知”就带着上次的错误残留。错误会随着轮次不断传播、叠加，直到某次表现异常才被人察觉——而这时候要追溯原因已经非常困难了，因为context已经被多轮任务的摘要弄得面目全非。
我们管它叫**记忆污染（Memory Poisoning）**。
解法不是不用context记忆，而是要分清两种不同类型的信息：
```python
# memory_strategy.py
# 类型 A：事实性状态（不会过期、不会出错）
# 存数据库，Agent 每次启动时查询，不放进 context
FACTUAL_STATE = {
"published_articles_today": "SELECT COUNT(*) FROM audit WHERE action='publish' AND date=today()",
"pending_tasks": "SELECT COUNT(*) FROM task_queue WHERE status='pending'",
"last_run_at": "SELECT MAX(completed_at) FROM task_queue WHERE status='completed'"
}
# 类型 B：上下文理解（当前任务内有效，跨任务无效）
# 只放进单次任务的 context，任务完成后丢弃
EPHEMERAL_CONTEXT = [
"当前任务的用户意图",
"这次调用的中间结果",
"临时的推理过程"
]
# 错误的做法：把 B 类信息持久化到下次任务
def wrong_approach():
summary = agent.summarize_last_run() # 包含了错误的中间状态
next_context = f"上次运行摘要：{summary}\n\n{new_task}"
# 错误传播了
# 正确的做法：用数据库存 A 类，B 类每轮清空
def right_approach(new_task):
# 每次启动时，从数据库查询干净的事实状态
state = db.query_state(FACTUAL_STATE)
fresh_context = f"""
当前事实状态（来自数据库，不是上轮摘要）：
- 今日已发布：{state['published_articles_today']} 篇
- 待处理任务：{state['pending_tasks']} 个
当前任务：{new_task}
"""
return fresh_context
```
做了这个改动之后，我们的Agent在连续运行48小时后，性能没有再出现之前观察到的那种“越跑越奇怪”的现象。不是因为Agent变聪明了，而是因为它每次启动时，拿到的是干净的事实，而不是上次推理残留的“过期记忆”。
## 运维债 5：成本归因——不知道钱花在哪，就不知道该砍哪里
我们用Agent跑了7天之后，算了一笔token账单：结果比预期高了2.3倍。
高在哪儿？这才是真正的问题——我们说不清楚。
Agent每天跑很多任务，每个任务都消耗token，但我们没有一个按任务类型聚合的账单。结果就只看到一笔总账，根本没法做决策：是某些类型的任务本身就比较贵？还是某个步骤在无效循环？是context带得太多？还是工具调用太频繁？
补上成本归因，只需要一个中间件层：
```python
# token_tracker.py
import time
from dataclasses import dataclass, field
from typing import Optional
import sqlite3
@dataclass
class TokenRecord:
task_id: str
task_type: str # 'write_draft', 'publish_check', 'research', etc.
model: str
input_tokens: int
output_tokens: int
cost_usd: float
step: str # 任务内的步骤名
timestamp: float = field(default_factory=time.time)
# 按任务类型的成本汇总（一周数据）
COST_SUMMARY_QUERY = """
SELECT
task_type,
COUNT(*) as task_count,
SUM(input_tokens) as total_input,
SUM(output_tokens) as total_output,
ROUND(SUM(cost_usd), 4) as total_cost_usd,
ROUND(A VG(cost_usd), 4) as a vg_cost_per_task
FROM token_records
WHERE timestamp > strftime('%s', 'now', '-7 days')
GROUP BY task_type
ORDER BY total_cost_usd DESC;
"""
```
跑了这个查询之后，我们看到了一个表格，数据很说明问题：
| 任务类型 | 任务次数（7天） | 总成本（USD） | 单次均价 | 占比 |
|---|---|---|---|---|
| `research_topic` | 34 | $4.21 | $0.124 | 38% |
| `write_draft` | 19 | $3.87 | $0.204 | 35% |
| `publish_check` | 89 | $1.44 | $0.016 | 13% |
| `format_review` | 56 | $0.98 | $0.018 | 9% |
| `context_summary` | 203 | $0.56 | $0.003 | 5% |
`context_summary`这个任务单次执行成本确实很便宜，但它竟然跑了203次——比所有其他任务加起来还多。往下钻了一层才发现，原来是有一段逻辑，在每次工具调用前都会重新对全量context进行一次summarize。这个无效的调用，不改代码根本发现不了，因为从日志里看它一切“正常”。
修掉这个bug之后，下一周的账单直接降了31%。
这就是成本归因的价值所在——不是要你去削减Agent的能力，而是帮你精准定位那些**功能上冗余、费用上昂贵**的无意义调用。
## 5 笔债的优先级和实施顺序
不是所有团队都需要马上补这5项，按影响和成本排一个优先级更实际：
| 债务 | 不补的最坏后果 | 实施成本 | 建议优先级 |
|---|---|---|---|
| 权限矩阵 | Agent 误触不可逆操作（删除/外发） | 低（2小时填表） | **P0** |
| 失败分类 | 重试产生副作用，被平台标记异常 | 中（1天代码） | **P0** |
| 人工接管 | 异常时只能强杀，状态损坏 | 中（1天代码） | **P1** |
| 记忆清洗 | 长跑后 Agent 行为越来越不可预测 | 中（半天重构） | **P1** |
| 成本归因 | 账单说不清楚，优化无法决策 | 低（几小时加日志） | **P2** |
权限矩阵是最快能上手的——不需要写代码，只需要团队坐下来填一张表，达成共识。但恰恰是这种“不需要写代码”的事情，在工程师团队里最容易被一拖再拖。
有个观察可能反直觉：**权限矩阵的主要价值，其实不是防止Agent乱来，而是防止团队里的人对“Agent能做什么”各执一词。** 出了事之后你会发现，5个人里可能有3种完全不同的理解——有人以为Agent不能改配置，有人以为只要有API Key就能改。矩阵的价值，正是用来消除这种信息差。
## 我们在第 7 天发现的真正问题
7天的运维经历之后，如果只把所有问题归结为“技术债”，感觉有点过度简化了。
真正的问题在于：团队接入Agent的速度，远远快于团队建立起 **“对Agent的共同认知”** 的速度。
每个人都知道“我们有个Agent在跑着”，但没有人能说清楚：
- 它今天做了什么（→ 需要审计日志摘要）
- 它有什么权力（→ 需要权限矩阵）
- 出问题了谁负责（→ 需要明确值班角色）
- 长期跑下去成本怎么算（→ 需要成本归因）
这些问题，本质不是工程问题，而是团队内部的信息对齐问题。工程机制——代码、协议、日志——都只是手段，真正的目标是让团队里每个人对Agent的边界和能力范围，有一个一致、清晰的认知。
## 可复制的治理清单
把上面5项整理成团队可以直接拿去执行的检查清单：
```
## AI Agent 治理清单 v1（openclaw-lab 验证）
### 上线前（必须）
- [ ] 权限矩阵填写完成，所有不可逆操作标注 或 （需审批）
- [ ] 失败分类逻辑实现：区分 transient / structural / side_effect
- [ ] 人工接管端点存在：至少支持 pause 和 resume
- [ ] 幂等 key 设计：发布/外发类操作必须有去重机制
### 上线后 7 天内（建议）
- [ ] context 记忆策略审查：事实性状态从数据库读，不从上轮摘要读
- [ ] 成本归因上线：按任务类型拆分 token 消耗
- [ ] 审计日志接入：记录所有产生外部副作用的操作
### 持续运营（每周）
- [ ] 有人每天花 5 分钟看 Agent 审计摘要
- [ ] 每周一次成本查询，识别异常涨幅
- [ ] 每两周回顾一次权限矩阵，是否有权限需要收紧
```
这张清单当然不完整，也不需要追求一步到位。**它的目标，是帮助团队在7天内建立起最基础的可见性，而不是一下子就搭建起一个完善的Agent治理平台。**
## 常见问题
**Q：权限矩阵应该做到多细粒度？操作级还是接口级？**
A：从操作语义级别开始，不要从接口级别开始。“发布文章”比“调用 /api/v1/posts POST”更容易让团队达成共识——前者人人都能理解，后者只有写代码的人才看得明白。接口级权限是实现细节，而矩阵是团队共识文档。两个层面都需要，但不要混在同一张表里。
**Q：记忆污染一般要多久之后才会开始明显影响输出质量？**
A：根据我们的观察，携带历史摘要的Agent，一般在第5到第7个任务周期之后，会开始出现可察觉的偏差。比如，它在推断任务状态时，会倾向于依赖“上次说过的话”，而不是工具实时返回的结果。这个拐点会因为context窗口大小、摘要质量以及任务类型的不同而有所差异。没有通用的固定数字，但有一点可以肯定：“三天不出问题不代表没问题”——这种变化通常是渐进的，需要主动去测试，不能等到出现明显异常才开始排查。
**Q：成本归因应该是实时的还是离线的？**
A：建议先做离线的。用一个简单的数据库（比如SQLite）存下每次大模型调用的token数和模型名，每天跑一次汇总查询。对大多数团队来说，离线日报的信息密度已经足够支撑决策了。不需要一开始就搞实时监控面板。等到你真的识别出需要实时告警的指标——比如某类任务成本突然涨了50%——再考虑上实时的监控。从离线查询开始，工程成本最低，先验证了价值，再决定是否要投入更多。