AI-native 时代，真正的瓶颈不是自动化，而是协调设计
这两年，大家谈 AI，最常见的叙事还是“自动化”：写代码自动化、客服自动化、运维自动化、内容生产自动化。这个叙事并不完全错，但它越来越不够用了。
因为在很多真实场景里，难点已经不是“某个动作能不能被模型做掉”，而是：这项工作应该如何被定义、拆分、委派、复核、升级，以及最终由谁承担责任。
也就是说，AI-native work 的核心挑战，正在从 execution 转向 coordination。
这不是一个措辞上的微调，而是工作组织方式的变化。过去，我们优化的是单点效率；现在，我们必须设计一整套 task flow：谁发起、谁判断、谁审核、谁兜底、什么时候升级到 human、出了问题谁 accountable。瓶颈不再只是“模型够不够强”，而是“系统有没有把 judgment、prioritization 和 accountability 安排清楚”。
自动化叙事，为什么已经不够解释现实
把 AI 理解成自动化工具，默认前提是：流程本身已经清晰，规则基本稳定，只差一个更便宜、更快的执行器。这种前提在 OCR、表单归类、基础问答等场景里成立，但一旦进入稍微复杂一点的知识工作，就会迅速失效。
原因很简单：现实工作里，大量成本并不发生在“做”这一步，而发生在“决定做什么、做到什么程度、出现异常时怎么处理”。
以一个常见场景为例。让 Agent 去处理 incident、写变更说明、汇总日志、生成初步 RCA，这些动作本身并不稀奇。真正难的是下面这些问题：
- 哪类 incident 可以自动处理，哪类必须人工接管？
- Agent 给出的结论，什么条件下可以直接进入下一步，什么条件下必须 review？
- 当多个信号互相冲突时，谁来做最终 judgment？
- 如果自动操作造成影响，责任如何追踪？
这些问题本质上都不是 automation problem，而是 coordination problem。
一旦工作被多个 human、多个 agent、多个 system 共同完成，系统最脆弱的地方就不再是某个节点能不能执行，而是节点之间如何衔接、约束和问责。
Prompting 不是护城河，协调设计才是
很多团队最早进入 AI 的方式，是围绕 prompt 做优化：提示词模板、角色设定、few-shot examples、格式约束、输出风格控制。这些当然有价值，但如果把它当成长期 moat，判断往往会失准。
因为 prompting 更像是一种接口适配能力，而不是组织能力。模型在快速进化，基础提示技巧会被产品化、框架化、平台化。今天需要精细手调的 prompt，明天可能就会被更强的 model、tool calling、structured output 或 workflow engine 吃掉。
真正难以被复制的，不是“你会不会写一个更聪明的 prompt”，而是你有没有设计出一套稳定、可扩展、可审计的 coordination mechanism。
高价值能力越来越像几种 loop 的组合：
- Delegation loop：任务如何拆解并分派给不同 agent 或工具
- Review loop：结果如何被验证、打回、修正
- Escalation loop：遇到高风险、不确定、越权场景时，如何升级给 human
- Control loop：系统如何持续监控、度量、纠偏，并在必要时收紧权限
从这个角度看，prompt 只是局部实现细节；coordination design 才是系统级能力。前者决定输出是否“像样”，后者决定系统是否“能上生产”。
协调设计的四个层次
如果把 AI-native work 当成一种新的 operating model，我更倾向于从四层来理解它。
1. Task definition：先定义任务，不是先调用模型
很多失败，并不是模型做不好，而是任务定义本身含糊。
“帮我处理一下告警”不是 task definition，“识别告警类型、补齐上下文、给出处置建议，禁止执行任何写操作，置信度低于阈值必须升级人工”才是。
AI 系统首先要回答的不是“能做什么”，而是：
- 输入边界是什么？
- 输出契约是什么？
- 成功标准是什么？
- 禁止事项是什么？
没有清晰的 task contract，后面的 delegation 和 review 都会变得脆弱。
2. Delegation boundary：划清可委派边界
Agent 的价值不在于“尽可能多做”，而在于“只做应该委派给它的事”。
这是很多团队最容易走偏的地方：一旦看到 agent 能连续完成多个动作，就倾向于继续放权。但在 production environment 里，放权不是能力问题，而是 governance 问题。
一个成熟系统应该明确区分：
- 可完全委派的机械性任务
- 可部分委派但必须 review 的判断型任务
- 必须由 human owner 保留的责任型任务
例如：信息收集、日志归纳、草稿生成，通常适合委派；
而优先级裁决、风险接受、跨团队协调、生产变更批准，这些通常应保留 human ownership。
3. Review and escalation：把“复核与升级”做成默认机制
很多 AI demo 的逻辑是“一次生成，直接输出”；但现实系统更像“生成—复核—纠偏—必要时升级”。
这意味着 review 不是补丁，而是主流程。
Escalation 也不是失败路径，而是安全路径。
如果一个 agent system 没有显式设计以下问题，它大概率还没准备好进入核心流程：
- 哪些输出必须二次验证？
- 哪些异常信号触发人工介入？
- 升级时需要携带哪些 context，避免 human 从零接手？
- 人工驳回后，系统如何吸收反馈，而不是重复犯错？
4. Accountability：最后一定要落到责任归属
AI-native work 最容易被掩盖的问题，是责任模糊化。
当任务经过 planner、executor、reviewer、tool、human approver 多个环节后，大家很容易说：“这不是我决定的，是系统自动跑的。”
但真正可运营的系统，必须反过来设计：
每个关键决策点都要能回答，谁定义了规则，谁批准了权限，谁对最终结果负责。
没有 accountability，所谓 autonomous system 只是在制造新的组织黑箱。
对 Agent Systems 和 AIOps 的真正启发
这套视角对 agent systems 尤其重要，对 AIOps 更是如此。
AIOps 长期容易被理解为“让系统自动修更多故障”。但在真实运维场景里，最昂贵的不是少按几个按钮，而是误判、误操作、误升级带来的连锁影响。因此，关键问题从来不是“agent 能不能自动执行 remediation”，而是：
- 它在什么条件下有权执行？
- 执行前是否必须经过 policy check？
- 是否有 blast radius 控制？
- 是否有 rollback 预案？
- 谁是这个动作的最终 owner？
换句话说，AIOps 的先进性，不体现在让 agent 拿到更多能力，而体现在你是否有能力精确定义 delegation policy。
这同样适用于更广义的 agent product。一个真正有产品力的 agent，不是因为它“什么都能做”，而是因为它能在复杂环境里稳定地知道：
- 什么时候该自主
- 什么时候该求证
- 什么时候该停下
- 什么时候必须把 decision 权交还给人
这才是 control plane，而不只是 execution engine。
一份实用的协调设计 checklist
如果你正在设计 agent workflow，下面这份 checklist 比“怎么写 prompt”更值得优先回答：
1. 任务层
- 任务输入、输出、约束是否明确？
- 是否有结构化的 success criteria？
- 是否定义了不可接受结果？
2. 权限层
- Agent 可调用哪些 tools、可访问哪些数据？
- 哪些动作是 read-only，哪些涉及 write / execute？
- 高风险动作是否需要 approval gate？
3. 评审层
- 是否有自动 review 或 human review 机制？
- review 是抽样制，还是风险分级制？
- 失败样本是否能回流到流程设计里，而不只是优化 prompt？
4. 升级层
- 哪些条件触发 escalation？
- 升级给谁？SRE、on-call、manager 还是 domain expert？
- 升级时是否附带完整 context 和 decision trace？
5. 责任层
- 谁拥有任务定义权？
- 谁拥有放权边界的批准权？
- 出现事故后，能否追溯到规则、输入、输出和审批链路？
如果这些问题回答不清，那么系统再“智能”，也只是在不稳定地放大组织噪音。
结语：未来竞争，不是谁自动化更多，而是谁协调得更好
AI-native work 不会简单地把人从流程里移除，而是会重新安排人和机器在流程中的位置。
因此，未来组织的竞争力，未必来自“自动化率更高”，而更可能来自“协调设计更成熟”。
Prompting 会继续重要，但它越来越像基础能力；真正稀缺的，是把 delegation、review、escalation、control 和 accountability 编排成一个可靠系统的能力。
所以，面向 agent systems 和 AIOps，我的判断很明确：
关键不是让 agents 做更多，而是更清楚地决定什么可以交给 agents，什么必须由人持有。
当 bottleneck 从 execution 转向 judgment，当效率问题转向责任问题，AI 的主战场也就变了。
下一个阶段，拼的不是谁更会“生成”，而是谁更会“组织”。
