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遇到高风险、不确定、越权场景时如何升级给 humanControl 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 gate3. 评审层是否有自动 review 或 human review 机制review 是抽样制还是风险分级制失败样本是否能回流到流程设计里而不只是优化 prompt4. 升级层哪些条件触发 escalation升级给谁SRE、on-call、manager 还是 domain expert升级时是否附带完整 context 和 decision trace5. 责任层谁拥有任务定义权谁拥有放权边界的批准权出现事故后能否追溯到规则、输入、输出和审批链路如果这些问题回答不清那么系统再“智能”也只是在不稳定地放大组织噪音。结语未来竞争不是谁自动化更多而是谁协调得更好AI-native work 不会简单地把人从流程里移除而是会重新安排人和机器在流程中的位置。因此未来组织的竞争力未必来自“自动化率更高”而更可能来自“协调设计更成熟”。Prompting 会继续重要但它越来越像基础能力真正稀缺的是把 delegation、review、escalation、control 和 accountability 编排成一个可靠系统的能力。所以面向 agent systems 和 AIOps我的判断很明确关键不是让 agents 做更多而是更清楚地决定什么可以交给 agents什么必须由人持有。当 bottleneck 从 execution 转向 judgment当效率问题转向责任问题AI 的主战场也就变了。下一个阶段拼的不是谁更会“生成”而是谁更会“组织”。
AI-native 时代，真正的瓶颈不是自动化，而是协调设计
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遇到高风险、不确定、越权场景时如何升级给 humanControl 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 gate3. 评审层是否有自动 review 或 human review 机制review 是抽样制还是风险分级制失败样本是否能回流到流程设计里而不只是优化 prompt4. 升级层哪些条件触发 escalation升级给谁SRE、on-call、manager 还是 domain expert升级时是否附带完整 context 和 decision trace5. 责任层谁拥有任务定义权谁拥有放权边界的批准权出现事故后能否追溯到规则、输入、输出和审批链路如果这些问题回答不清那么系统再“智能”也只是在不稳定地放大组织噪音。结语未来竞争不是谁自动化更多而是谁协调得更好AI-native work 不会简单地把人从流程里移除而是会重新安排人和机器在流程中的位置。因此未来组织的竞争力未必来自“自动化率更高”而更可能来自“协调设计更成熟”。Prompting 会继续重要但它越来越像基础能力真正稀缺的是把 delegation、review、escalation、control 和 accountability 编排成一个可靠系统的能力。所以面向 agent systems 和 AIOps我的判断很明确关键不是让 agents 做更多而是更清楚地决定什么可以交给 agents什么必须由人持有。当 bottleneck 从 execution 转向 judgment当效率问题转向责任问题AI 的主战场也就变了。下一个阶段拼的不是谁更会“生成”而是谁更会“组织”。
