最近我在设计一个业务流程的 Agent 协作空间。这个空间不是给某个单点工具做交互壳，也不是把一批 Agent 放进一个聊天窗口里，而是要承载真实业务流程中人、系统、数据、规则和 Agent 的协同关系。
这个问题一旦进入真实流程，传统 workflow 的局限就会被放大。我们很容易先画一张流程图：第一个节点做什么，第二个节点调用谁，第三个节点审批什么，异常时回退到哪里。这样做在单线流程里可以成立，但在复杂业务里会迅速变脆。
我最初也沿着这个方向思考。后来发现，真正困难的不是把流程图画完整，而是传统流程图无法表达一个事实：业务协同并不是由“节点顺序”驱动的，很多时候是由“上下文变化”驱动的。
端到端营销活动只是一个非常典型的放大镜。活动负责人可能还在修改 brief，CDP 已经产出了第一版人群；内容 Agent 正在为高价值用户生成文案，法务同时在审核另一个素材；某个渠道已经开始投放，另一个渠道还在等待签名审核；数据看板刚回传一组异常指标，优化 Agent 就需要提出预算调整建议。
如果这时系统仍然只问“流程走到第几步”，这个问题本身就已经偏了。更有价值的问题应该是：哪份业务上下文发生了变化，谁依赖这份上下文，谁应该被激活，激活后又会写回什么结果。
所以这篇文章真正要讨论的，不是营销活动怎么自动化，而是一个新的编排和 Agent 协同范式：当业务流程进入 AI 时代，我们到底应该继续用 workflow 硬编排一切，还是重新构造一个围绕上下文运行的协作空间。
我的判断很明确：业务流程的下一代编排，不是把 Agent 塞进原来的节点里，而是把流程从“节点控制”升级为“上下文驱动的协同网络”。这不是一句概念包装，它会直接改变系统结构、Agent 角色、人机分工和流程可追踪方式。
一、最大的误区：把 Agent 协同理解成流程节点自动化
如果只是把每个流程节点换成一个 Agent，这不是新范式，只是旧流程的 AI 外包。
现在很多业务流程 AI 化方案，本质上仍然停留在节点替换。原来由人写文案，现在让内容 Agent 写；原来由人审核材料，现在让合规 Agent 先看；原来由运营看数据，现在让优化 Agent 给建议。表面上看，系统里出现了很多 Agent，但底层抽象没有变。
这种做法的问题在于，它默认流程已经被正确切分，默认节点边界稳定，默认所有上下游关系都能提前画出来。可复杂业务最麻烦的地方，恰恰是边界和依赖在运行中才浮现。
一个营销活动看似可以写成 brief -> 人群 -> 内容 -> 审核 -> 投放 -> 优化 -> 复盘，但真实运行中，内容、审核、投放、数据反馈并不是整齐排队的。它们会交叉、并行、部分完成、局部失败，并且持续产生新的判断依据。
所以，Agent 协同的设计对象不应该只是“流程第几步调用哪个 Agent”。真正要设计的是：Agent 在什么上下文下进入，读取哪些信息，承担什么责任，产生什么结果，以及这个结果如何改变后续协同。
二、Workflow 管顺序，协作空间管上下文
传统 workflow 的强项是控制顺序，AI 协作空间的强项应该是组织上下文。
这两者不是简单替代关系。审批流、任务流、状态机仍然重要，因为企业需要权限、状态、责任和审计。但如果把所有协同都压进固定节点，系统就会失去表达复杂业务的能力。
我在设计业务流程协作空间时，最核心的变化是把“流程节点”降级，把“业务上下文”升级。上下文不是聊天历史，也不是一段提示词，而是业务中可被识别、可被订阅、可被版本化、可被追踪的关键信息。
以营销活动为例， campaign.brief 代表目标和约束， audience.segments 代表人群分层， creative.copy 代表可投放文案， compliance.review_result 代表审核结论， performance.metrics 代表运行指标， optimization.suggestion 代表调整建议。
这些上下文一旦被结构化，系统就不再只依赖“下一步节点”。内容 Agent 看到 brief 和人群后可以行动，合规 Agent 看到文案和素材后可以行动，优化 Agent 看到指标偏离后可以行动，负责人看到高风险调整建议后再介入判断。
这就是协作空间和普通流程图的根本区别。流程图要求所有参与者沿着预设路径移动；协作空间要求每个参与者围绕共同上下文做出受约束的响应。
三、硬编排的诊断：它把运行时才知道的东西提前画死
复杂流程最危险的地方，不是分支多，而是分支在运行中才出现。
硬编排的问题，通常不是第一天暴露。刚开始你可以把活动、合同、采购、交付、售后这些流程拆成节点，也可以把每个节点分配给人、系统或 Agent。真正的问题出现在业务维度开始动态膨胀之后。
营销活动里，人群数量、渠道数量、素材版本、实验组合，往往不是设计期就确定的。今天可能只有 3 个人群，明天可能扩展到 12 个；今天只有短信和 Push，明天可能加入站内信、信息流和私域触达；某个素材被合规驳回，另一个渠道却已经在回传数据。
如果用硬编排表达这些变化，流程图会很快膨胀成大量分支。更严重的是，系统会把正常的业务变化当成异常处理，把本来应该自然展开的协作关系变成补丁、回退和人工干预。
上下文驱动的编排范式处理这类问题的方式不同。它不急着画出所有分支，而是先定义实体和维度：人群、渠道、版本、指标、审核状态、优化建议。这样一来， performance.metrics(channel=Push, segment=silent_users, variant=B) 就不是某条分支上的附属结果，而是一个可以被监听、分析和追踪的业务事实。
这也是我认为协作空间必须建立在上下文契约之上的原因。没有契约，Agent 只能被流程调用；有了契约，Agent 才能围绕业务事实协同。
四、新范式的核心：从中心化流程控制，转向上下文驱动编排
新的编排不是取消流程，而是把流程从唯一控制源改造成协同协议的一部分。
这里需要把话说清楚。我并不是反对 workflow，也不是主张所有业务都变成自由对话。企业流程必须有边界，必须有权限，必须有日志，必须有人工确认点。问题在于，传统 workflow 不应该继续垄断全部协同抽象。
我更愿意把下一代业务流程协作空间拆成四层：参与者注册、上下文契约、监听行动规则、运行记录。这四层合在一起，才构成一种新的 Agent 协同编排机制。
第一层是参与者注册。参与者可以是人、Agent、外部平台、数据系统或审批系统。每个参与者都要声明自己的身份、能力、输入依赖、输出结果和责任边界。内容 Agent、合规 Agent、优化 Agent、活动负责人、CDP、投放平台，本质上都是协作空间里的参与者。
第二层是上下文契约。系统不能允许任何参与者随意写入一个模糊的 key。每个上下文都要定义作用域、实体类型、来源、消费者、状态、版本和结构。这样，业务信息才不会沦为一堆无法治理的 KV。
第三层是监听行动规则。规则不再写“下一个节点是谁”，而是写“谁监听什么上下文，在什么条件下行动，行动后写回什么结果”。这使 Agent 的执行从被动调用转向条件触发，也让人类判断能够在真正需要的位置介入。
第四层是运行记录。每一次上下文变化、每一次规则命中、每一次 Agent 激活、每一次人工确认，都应该进入事件记录。这样流程图不再靠人事后补画，而是可以从真实运行轨迹中生成。
五、上下文契约，是 Agent 协同的真实接口
没有上下文契约的 Agent 协同，最后一定会退化成提示词拼接和人工兜底。
在普通系统集成里，我们会认真定义 API；但到了 Agent 协同里，很多人反而开始相信“把信息都放进上下文就行”。这是一个危险的误区。业务上下文不是越多越好，而是要被结构化、被约束、被版本管理。
以 creative.copy 为例，它不能只是“某段文案”。系统必须知道它属于哪个活动、哪个人群、哪个渠道、哪个版本；是谁生成的，谁审核过，谁消费它，当前状态是什么，被驳回后产生了哪个新版本。
我会把它定义成类似这样的契约： key: creative.copy， scope: segment + channel + variant， entityType: campaign_dimension， provider: content_agent， consumer: brand_owner, compliance_agent, design_system， schemaVersion: v1。
这个定义的意义不在于格式本身，而在于它把“文案”从一段内容变成了一个有归属、有状态、有消费者、有版本的流程对象。只有这样，合规 Agent 才知道自己审的是哪一版，设计系统才知道该处理哪份素材，投放平台才知道哪些内容具备上线条件。
同样， performance.metrics 也不能只是一个总点击率。它必须能表达“Push 渠道 + 沉默用户 + 文案 B”这一组业务事实。否则优化 Agent 给出的建议，就无法被定位、验证和追责。
六、Agent 的新位置：从工具调用，变成可追踪参与者
Agent 只有拥有输入边界、行动条件和写回责任时，才算进入了业务协同。
很多 Agent 项目看起来热闹，本质上还是工具调用。流程走到某一步，系统把材料丢给 Agent，Agent 生成一段结果，流程再继续往下走。这样的 Agent 更像一个增强 API，而不是协作空间里的参与者。
真正的参与者必须能回答四个问题：我监听什么上下文，我在什么条件下行动，我行动时允许读取哪些信息，我行动后必须写回什么结果。回答不了这四个问题，Agent 就没有稳定的组织位置。
内容 Agent 不应该被写成“第 3 步调用内容生成”。它应该声明自己监听 campaign.brief 和 audience.segments，当 brief 已确认且人群包存在时，生成 creative.copy 和 creative.variants。
合规 Agent 不应该被写成“第 5 步审核”。它应该监听 creative.copy、 creative.assets 和 landing_page.content，在内容进入 ready 状态后写回 compliance.review_result，并把通过、驳回、修改建议写入版本记录。
优化 Agent 也不应该等流程走到“优化节点”才出现。它应该持续监听 performance.metrics，当某个指标低于基线或 ROI 低于目标时，写回 optimization.suggestion 和 budget.adjustment_plan，必要时触发人工确认。
这就是 Agent 协同范式和传统工作流调用的差别。前者强调参与者契约，后者强调节点执行顺序。
七、人的新位置：从流程搬运者，变成判断边界的负责人
AI 协作空间不是为了让人消失，而是把人从低价值跟单中释放到关键判断上。
这也是我认为这套设计必须严肃对待的原因。企业流程不是一个技术对象，它背后有授权、责任、风险和组织信任。Agent 可以生成建议，可以读取数据，可以触发动作，但并不天然拥有组织授权。
在新的协作空间里，人不应该再承担所有节点的搬运、催办和重复确认。活动负责人不需要盯着每个渠道是否进入下一步，但必须确认目标、预算边界、异常策略和高风险调整。品牌负责人不需要看所有草稿，但必须审核影响品牌表达的关键内容。法务不需要被动等待流程流到自己，但必须在隐私、授权、合规风险出现时被系统准确唤起。
这意味着，人的工作位置发生了迁移。人从流程执行者的一部分，变成上下文网络里的判断者、授权者和例外处理者。系统要做的不是绕开人，而是让人只在真正需要判断的上下文里出现。
如果一套 Agent 协同系统没有设计人工确认点、责任留痕和异常暂停机制，它就不是严肃的企业流程系统。它可能能演示，但很难进入真实组织。
八、流程图的新位置：从执行源，退到解释层和观测层
成熟的 AI 协作空间不是不要流程图，而是不再让流程图垄断系统运行。
流程图仍然有价值。它可以帮助管理者理解业务结构，可以帮助流程负责人审查规则，也可以帮助团队复盘运行轨迹。但它不应该再被当成复杂协作的唯一执行源。
在上下文驱动的协作空间里，预期流程图可以从配置生成：谁提供哪些上下文，谁监听哪些上下文，中间有哪些依赖关系。运行轨迹图则应该从真实事件生成： context.changed -> participant.activation -> output.context -> human.confirmation。
这样生成出来的图，比传统流程图更接近业务事实。它可以解释哪份人群数据触发了哪次内容生成，哪份文案触发了哪次合规审核，哪条指标触发了哪次预算调整，哪次人工确认改变了后续渠道策略。
这也解释了为什么我把这个系统称为协作空间，而不只是 workflow 平台。workflow 平台强调“流程怎么走”，协作空间强调“人、Agent、系统如何围绕共同上下文形成可追踪协同”。
九、这套范式的实践路径：先做协同协议，再画流程图
如果先画流程图，再往里塞 Agent，系统大概率会回到旧范式。
我现在更倾向的实践路径，是反过来做。先选择一个足够复杂、但边界相对清楚的业务流程，例如端到端营销活动、合同评审、采购寻源、客户投诉处理或交付风险管理。然后不要急着画全流程，而是先盘点这个流程里真正驱动协同的上下文。
这些上下文可能包括目标、约束、实体、材料、规则、风险、指标、建议、审批结论和复盘洞察。每个上下文都要定义来源、消费者、作用域、版本、状态和可见权限。只有这一步做清楚，后面的 Agent 才不是散兵游勇。
接下来，把每个参与者注册进协作空间。人、Agent、系统都要声明能力和责任边界。内容 Agent 负责生成，合规 Agent 负责审查，优化 Agent 负责发现异常，负责人负责确认高风险动作，外部平台负责写入事实数据。
最后再定义监听行动规则，并用运行事件生成流程图。此时流程图不是凭想象画出来的，而是从上下文依赖和真实运行轨迹中长出来的。这就是新编排范式和传统 workflow 的本质差异。
这四步做完，系统的设计重心会发生明显变化。你不再试图把复杂流程压缩进一张越来越长的图，而是在构造一套可执行的协同协议。流程仍然存在，但它不再是唯一抽象；Agent 仍然执行任务，但它不再只是工具；人仍然介入流程，但只在真正需要判断、授权和负责的位置出现。
这就是我想探索和实践的新编排范式。它的目标不是让 AI 代替所有流程管理，也不是让 Agent 在企业里自由行动，而是为复杂业务建立一个可治理的人机协作空间。这个空间既能容纳流程的确定性，也能承认业务运行中的动态变化。
如果说传统 workflow 解决的是“事情按什么顺序推进”，那么新的 Agent 协同范式要解决的是“当业务上下文变化时，谁应该带着什么责任行动”。这句话，才是我对业务流程 AI 协作空间的核心设计理念。
公开资料补充：OpenAI Agents SDK 强调工具、handoff、guardrails、sessions 和 trace；Microsoft Semantic Kernel Agent Framework 强调多 Agent 协作与编排；AWS 事件驱动架构强调用状态变化触发响应。本文把这些原则迁移到企业业务流程设计中，核心不是追逐框架，而是把人、Agent、系统和业务上下文之间的协同关系做成可配置、可解释、可追踪的机制。