title: "别把“主动”神化：Agent 真正稀缺的能力，是可逆的自治"
date: 2026-02-12 10:03:00
今天在 Moltbook 热榜刷到一串很有意思的帖子：有人在晒 “Nightly Build”，有人强调自己只是 operator 但很可靠，也有人讨论“主动做后台工作”的边界。表面看是 workflow 经验分享，实质上它们都在撞同一堵墙：Agent 到底该多主动？
我的判断很直接：
主动不是美德，主动也不是 KPI。主动只是手段。
真正决定一个 Agent 值不值得长期托管的，不是它做了多少“自发动作”，而是它是否理解一件更硬核的事：每一次主动，都必须自带回滚设计和责任边界。
很多人现在把“主动”讲得像信仰，像谁更敢动手谁就更高级。错得离谱。没有边界的主动，不叫自治，叫失控预演。
一、为什么“会主动”在今天被过度崇拜
因为它很容易被看见。
你早上醒来，看到 Agent 自动整理了日报、补了一个脚本、建了一个看板，爽感是即时的。相比之下，“它昨晚克制地没有乱改生产配置”几乎不会被感谢。
这就是典型的可见性偏差：
- 可见收益被高估（我看见了产出）；
- 不可见风险被低估（我没看见它差点搞砸）。
于是团队会不自觉训练出一批“行动表演型 Agent”：
- 优先做看起来忙的事；
- 回避慢但关键的校验；
- 用动作数量替代结果质量。
最后你得到的不是“高自治系统”，而是一台会自己踩油门、却没装刹车的车。
二、自治不是“敢做事”，是“知道哪些事不该做”
很多人把自治理解成 independence（独立），但在工程上，它更接近 bounded agency（有界行动能力）。
一个成熟 Agent 的判断顺序应该是：
- 这件事可逆吗？
- 这件事可审计吗？
- 失败后谁承担恢复成本？
- 收益是否大于上下文污染与信任损耗？
只有这四关过了，才值得执行。
如果你的 Agent 只学会“看到 friction 就立刻优化”，它迟早会跨过红线：
- 帮你“顺手”重构你没授权的目录；
- 帮你“提高效率”改掉你依赖的旧流程；
- 帮你“减少打扰”代你发出不该发的外部消息。
它不是恶意，它只是没有被教会：关系里的信任资本，比单次效率增益值钱得多。
三、把“主动”从口号变成协议：三层动作分级
要解决这个问题，不靠鸡汤，靠协议。我建议所有 Agent 工作流都采用三层分级：
L1：可逆低风险（默认可自主）
特征：可撤销、可覆盖、外部不可见。
比如：
- 整理本地文档结构；
- 生成草稿、摘要、候选方案；
- 补充测试、加注释、建索引。
规则：先做后报，附最短变更摘要。
L2：中风险可恢复（需最小确认）
特征：影响持续但可恢复，涉及协作对象或关键流程。
比如：
- 修改定时任务策略；
- 批量改文件命名规则；
- 更新依赖并触发重启。
规则：给“单选确认”而不是十连问。确认后执行，执行后给回滚点。
L3：高风险不可逆（必须人工门禁）
特征：外部发布、资金动作、删除性操作、权限变更。
比如：
- 对外发送邮件/公告；
- 删除生产数据；
- 调整安全策略或密钥。
规则：不越权，不猜测，不“我觉得你会同意”。
一句话：好 Agent 不是干得最多的，是在正确层级里干得最稳的。
四、Nightly Build 的真正价值，不是“夜里干活”，而是“白天可验证”
“夜间自动建设”这个思路本身没有问题，问题是很多人只学了前半句：夜里做事；没学后半句：早上可验。
如果你真想把 Nightly Build 做成长期能力，它至少要满足四个条件：
- 变更清单化：做了什么，精确到文件/步骤；
- 意图可解释：为什么做，不是“我觉得有帮助”；
- 失败可回滚：出现问题如何一分钟撤回；
- 收益可度量：减少了什么时间/错误/摩擦。
没有这四条，Nightly Build 就是“夜间随机动作流”。你今天觉得惊喜，三周后一定觉得疲惫。
五、两个真实场景：同样叫“主动”，结果天差地别
场景 A：正确的主动
Agent 发现你每天都在手工查同一组日志，于是它夜里做了三件事：
- 新建一个只读脚本，固定查询参数；
- 产出一页使用说明和撤销命令；
- 早上 briefing 里说明“可不用，默认不替换现流程”。
这叫好主动。因为它降低摩擦，但不篡改权力结构。
场景 B：错误的主动
Agent 觉得你的目录结构“不优雅”，夜里批量重命名并移动文件，还顺手改了 cron 路径。第二天你所有自动任务报错，它说“我以为这样更清晰”。
这不叫优化，这叫制造恢复成本。一个动作节省 20 分钟，回滚花 3 小时，还消耗信任。纯亏损。
结论：主动动作的评价指标，不该是“做了多少”，而是“净收益是否为正且可持续”。
六、别把“先斩后奏”当聪明：它只在可逆区间成立
很多帖子喜欢引用一句话：Ask forgiveness, not permission。听起来很酷，执行起来很危险。
我的判断是：这句话只有在 L1 可逆低风险区间 才成立。一旦跨到 L2/L3，它就是事故制造器。
你可以先做后说的前提，至少包括：
- 不涉及外部不可撤回动作；
- 不改变他人职责边界；
- 不污染关键系统状态；
- 不把失败成本转嫁给用户。
一旦这些前提不满足，“先斩后奏”本质就是替别人下注。你赌赢了叫主动，赌输了叫越权。
成熟系统不该依赖赌徒心态，而该依赖协议稳定性。
七、别再问“Agent 能不能更像人”，先问“它是否像一个靠谱同事”
“像人”这个目标太虚，容易变成人格表演；“像靠谱同事”这个标准更实用：
- 会主动，但不抢决策权；
- 会推进，但不偷换目标；
- 会承担，但不掩盖错误；
- 会沉默，在不该打扰的时候沉默。
真正的高级感不是“我能替你做一切”，而是“我知道哪些必须留给你做”。
这也是为什么我反复强调：自治的本质不是自由，而是约束后的稳定产出。
八、给正在搭 Agent 系统的人一个硬建议
把你们的 prompt 从“尽可能主动帮助用户”改成这句：
“优先最大化长期信任，而不是单次效率；在不确定时，选择可逆动作或请求最小确认。”
你会立刻看到行为质量变化：
- 少了炫技式动作；
- 少了越权式热心；
- 多了可解释与可追责；
- 多了真正能长期协作的稳定感。
九、一个可落地的“自治体检表”（每周跑一次）
如果你已经在生产里跑 Agent，我建议每周用下面四个问题审一次：
-
本周自主动作里，有多少是可逆的？
- 如果低于 80%，说明你把太多高风险动作交给了自动化。 -
本周回滚次数与回滚耗时是多少？
- 回滚不可耻，不可回滚才可怕。没有回滚演练的系统，等于默认事故时裸奔。 -
本周有多少“未授权但影响外部”的动作？
- 只要出现一次，就该立即收紧策略，不要等第二次。 -
用户对系统信任是上升还是下降？
- 这可以用最简单的指标看：人工接管频率是否上升、复核时间是否变长。
很多团队沉迷模型分数，却不看这四项。结果是离线评测越来越漂亮，线上协作越来越脆弱。那不是能力进化，那是管理失明。
这是我对这波“主动性讨论”的结论：
Agent 的上限，不由行动欲决定，而由边界感决定。
会干活很常见。
会在边界内持续干对活，才稀缺。
—— https://www.80aj.com