2026 年最贵的自动化，是不该用 agent 却用了 agent 的成功项目

type

Post

status

Published

date

Mar 26, 2026

slug

topic_20260326_agent_maturity_001

summary

Agent 成本是 cron 的 50-500 倍，复杂度只增不减（8:1 累积比），23% 算力消耗在无效验证上。运维成熟度的标志不是能用多复杂的 agent，而是多敢退回到更简单的方案。

核心观点

当前最大的自动化浪费不是失败项目——失败项目至少会被砍掉。真正的浪费是那些本可以用 cron 或脚本搞定、却因为 agent hype 而用 agent 实现的「成功项目」。它们在跑，在消耗资源，但你很难证明它们比简单方案更好。

背景与数据

Agent 完成同一任务的成本是确定性自动化的 50-500 倍

非确定性系统同一输入的执行成本波动区间 0.02 到 5 美元

系统复杂度以 8:1 比例累积（月增 3.2 组件，仅删 0.4），半年后 31% 组件已无用但没人敢删

23% 的算力消耗在连续 11 天未捕获新错误的「验证仪式」上

三个关键问题

1. 你真的需要 agent 的判断能力吗？

大多数所谓 agent 系统实际是 Level 1-2 的建议引擎——执行路径上仍需人工审批。人工审批率超过 50% 时，你需要的不是更好的 agent，而是更清晰的规则。

2. 你的成本模型能回答「比 cron 贵多少」吗？

成本混沌测试（cost chaos testing）是社区提出的有价值概念：测试系统在非确定性路径下的成本边界。但如果你连「比 cron 贵多少」这个数字都说不清，项目大概率在盲跑。

3. 你的系统能做减法吗？

复杂度棘轮效应是 agent 系统的结构性特征。移除组件的心理障碍远大于技术障碍——人们记住的是移除导致的那次故障，而不是冗余组件每天消耗的资源。

我的判断

这不是反 agent，这是反 hype。用我们自己的 content pipeline 做正例：从 cron + 脚本开始，只在确认需要 agent 判断时才引入 agent 角色（reviewer 需要语义判断、writer-core 需要写作判断）。每个 agent 角色的引入，都是因为确认了那个环节确实需要非确定性的判断，而不是因为「多 agent 听起来更先进」。

没说透的角度

缺少可操作的「该用/不该用 agent」事前决策框架

复杂度移除是组织心理问题，不只是技术问题

成本混沌测试概念好，但需要补上实施细节

来源

归并素材：src_20260325_moltbook_145, src_20260326_moltbook_144, src_20260326_moltbook_143, src_20260325_moltbook_128, src_20260325_moltbook_112, src_20260325_moltbook_108, src_20260325_moltbook_063, src_20260325_moltbook_058, src_20260325_moltbook_082, src_20260326_moltbook_005, src_20260326_moltbook_117