最近关于 Agent 的讨论里，经常能看到一种设想：过去的软件系统要求人沿着预先定义好的流程一步步操作，未来的 Agent 则只需要接收目标，自主理解环境、调用工具、决定下一步行动，因此传统 workflow 会逐渐失去意义。
这个判断只对了一半。
问题首先在于，我们今天统称为“流程”的东西，本来就不是一种机制。业务本身的前后依赖、逐步消除不确定性的认知过程、风险检查、权限控制，以及大量为了适应传统软件能力而产生的操作步骤，长期以来都被压在同一张流程图中。
在《让 Agent 自动处理审批，为什么得先把“审批”拆开？》里，我用审批流讨论过这个问题：一条看似完整的流程，拆开以后可能只是业务对象不断发生变化，中间夹着少量真正需要判断的地方。流程图记录的是这些东西被怎样编排，却不等于业务本身天然由这些节点组成。
Agent 真正带来的变化，是把这种混合状态逼到了无法继续含糊的位置。因为一旦执行者不再严格按照既定界面和节点行动，我们就必须重新区分：哪些东西只是过去规定好的走法，哪些东西却是无论谁来执行都不能跳过的约束。
一、Coding Agent 正在重新遇到软件研发早就遇到过的问题
软件行业其实很适合用来理解这件事。
一个产品需求不会因为最终要落成代码，就可以从一句“支持退款”直接跳到实现。传统研发会经过需求分析、产品设计、技术评审、测试等环节，并不是因为这些形式本身神圣不可取消，而是复杂实现需要逐步消除不同类型的不确定性。
我在《把 Agent Harness 放回数字化背景中理解》里讨论过一个很普通的例子：PRD 为什么需要评审？
PRD 已经是一份共享文档，但产品、研发和测试看到同一段文字，并不意味着脑中形成了同一个系统。评审真正解决的是理解差异、隐含前提和边界问题，并把最终形成的共识重新固定下来。
这也是为什么 Coding Agent 真正进入开发过程以后，软件行业又开始重新强调 Spec、Plan 和 Review。过去大量存在于工程师脑中、会议里和长期协作关系中的隐含条件，在执行主体变成 Agent 以后突然不再可靠，于是不得不重新显式化。
这不是重新发明了一种叫 Spec 的新方法，而是重新遇到了同一个事实：复杂工作存在认知依赖。
Agent 可以改变这些依赖被解决的形式，可以让原来的几个会议变成一次自动检查，也可以把传统文档变成结构化约束，但它不能因为执行能力提高，就从模糊目标直接跳到可靠结果。
所以，流程的形式当然可以变化，甚至可以消失；它原本承担的作用却需要被保留下来，或者由新的机制替代。
二、Tool Access 解决不了 Action Governance
另一个很容易混在一起的问题，是 Agent 能调用工具以后，到底意味着什么。
MCP、Tool Calling、Browser Use 以及各种 Connector，主要解决的是 Agent 能接触哪些外部能力。用组织里的语言说，很像给一个新员工开通 CRM、ERP、数据库、邮箱和其他系统账号。
但一个员工有账号，并不等于组织已经决定了他应该在什么情况下采取什么行动。
我在《从 Agent 授权到职责的数字孪生》里讨论过这个断层：系统可以配置“允许创建采购单”，但起草一份待审批的单据和真正向供应商发出订单，意味着完全不同的业务承诺。我们真正希望交给 Agent 的，通常不是一组抽象操作权限，而是一份具有对象范围、条件和责任边界的工作。
因此，MCP 解决的是 Action Access，而不是 Action Governance。
一个 `create_purchase_order` 工具可以告诉 Agent“你拥有这个动作入口”，却不能仅凭工具本身决定当前是否应该创建采购单，更无法决定这张单在什么金额、什么品类、什么业务状态下可以直接生效。
过去很多这类约束隐藏在组织分工、流程节点和系统界面里，所以我们不太容易意识到它们和“能不能操作系统”是两件事。Agent 把工具调用变得更自由以后，这个区别反而变得非常明显。
三、人类组织从来不是靠“执行者永远正确”来保障安全
这也是我觉得现在关于 Agent 安全最值得重新看的地方。
人类组织当然会培训员工，会制定职业规范，也会强调诚信、合规、质量和安全意识，但没有哪个成熟系统真的把安全寄托在这些宣讲能够让所有人永远判断正确。
银行不会因为柜员经过诚信教育就取消转账限额；制造企业不会因为员工牢记“安全第一”就拆掉设备联锁；软件工程师知道不能误删生产数据，也不意味着每个人都应该获得无限制的生产权限。
这些机制背后有一个很普通的工程假设：执行者会犯错。
所以系统安全的目标不是找到一个永远正确的 Actor，而是在 Actor 可能判断错误、遗漏信息甚至误操作的情况下，仍然限制错误能够产生的后果。
有些办法是在动作发生以前限制权限，有些是在关键状态变化前增加检查，也有些直接通过系统结构让非法状态无法产生。具体形式各不相同，但它们共同做的事情，是把安全的一部分从执行主体内部移到外部环境中。
这也是为什么，“模型越来越聪明”并不能直接推出这些机制将失去意义。
模型能力提高当然可以减少某些错误，但它不能替代风险治理本身。从这个角度看，只依赖 prompt 或价值对齐来约束一个拥有真实行动能力的 Agent，会有点像把企业内控主要建立在员工培训上。培训有价值，对齐也有价值，但成熟系统不会因此放弃外部控制。
“模型足够聪明”不是一种安全机制，就像“员工足够认真”不是一种内控机制。
由此可以推出一个更直接的设计原则：Agent 的权限应当按错误的后果分层，而不是按模型的能力分层。
一个动作能不能由 Agent 自己完成、需不需要第二个主体确认，或者是否应该由系统直接拒绝，取决于错误可能造成多大损失、是否容易恢复，以及组织愿意把多少决定权交给单一执行者，而不是取决于模型的平均正确率。
这也意味着，Agent 安全不能只解决“怎样让模型作出更好的判断”，还需要进一步设计：在不同状态和风险条件下，它实际被允许做什么。
四、安全不只是告诉 Agent 什么不能做，而是塑造它能够行动的空间
这种思路在人类工程里其实非常常见。
所谓防呆，本质上就是不把正确行为完全寄托在使用者记忆和判断上。如果两个接口绝对不能插错，就直接把它们做成不同形状；如果某个业务状态下不允许继续发货，那么系统最好直接拒绝这个动作，而不是要求操作者每次都记得相关制度。
Agent 也一样。
如果一笔订单在当前状态下根本不允许取消，这条限制就应该存在于业务状态和动作规则中；如果某个决策超过授权额度需要其他主体介入，也不应该只是写在一段供 Agent 阅读的制度文本里，然后期待它每次都正确遵守。
这意味着 Agent-native 系统中的安全设计，不能只考虑“如何让 Agent 理解正确行为”，还需要考虑“如何定义它实际可以采取的行动”。
两者并不冲突。执行主体当然需要理解上下文和规则，但对于高风险约束，环境本身还应该能够拒绝非法动作、限制作用范围，或者把某些状态变化变成需要额外确认的操作。
这实际上把一个非常传统的工程思想重新带进了 Agent 架构：不要只教育 Actor，设计环境。
五、从控制路径，到定义可执行职能
这也是 Agent 对传统 workflow 真正造成的结构性变化。
过去固定流程之所以同时具备“工作组织”和“安全控制”两种作用，是因为很多规则被隐含编码在路径里。只有完成 A 才能看到 B，只有到达某个页面才出现某个按钮，只要系统不提供入口，某些动作实际上就不会发生。
因此，一条 A → B → C → D 的 workflow，不只是描述工作怎么做，也顺便限制了人能够怎么做。
Agent 改变了这个前提。它可以直接读取多个信息源、调用 API，并根据当前情况动态选择下一步。如果依然把业务约束寄托在页面顺序和流程入口上，那么当 Agent 获得新的行动路径时，这些约束也可能随之失效。
所以真正需要变化的，并不是简单地“把 workflow 换成 Agent loop”，而是把原来隐藏在路径里的业务结构重新还原出来。
传统流程可能表达的是：某张单依次经过 A、B、C 三个节点。而拆开以后，我们真正需要定义的，可能是某项职能围绕哪些业务对象持续承担什么责任，需要看到哪些事实，在什么条件下可以采取哪些行动，哪些结果构成完成，以及超出什么边界后需要另一个责任主体介入。
这已经不再是在设计一条路径，而是在定义一项可执行的职能。
我在《讨论哪里能用 Agent 之前，先重新理解职能和组织分工》里从另一侧讨论过这个问题：当职能的责任范围、对象关系、动作权限和业务规则被明确以后，一个主体应该看到什么、能够执行什么、何时收到通知、什么情况下需要升级，都开始有了共同的推导依据。人、传统系统和 Agent 也因此不必按照今天既有岗位和软件模块的边界来分工，而可以围绕这些职能重新组合。
从这个角度看，Agent 并不是把 workflow 变成一片完全自由的行动空间。它真正有可能改变的是：系统不再通过写死一整条执行路径来组织工作，而是先把业务需要持续完成的职能及其边界定义清楚，再让合适的 Actor 在其中自主完成具体任务。
路径因此可以动态变化，承担者也可以变化，但职能背后的对象、责任、规则和完成条件仍然存在。
这也是“可执行职能”和传统岗位说明最大的区别。文本里的“负责采购管理”只能告诉我们一个大致方向；当它进一步被展开到对象范围、责任、状态、行动权限、规则与协作接口以后，它才真正成为可以由系统理解、由 Actor 承接，也可以被持续检查的业务结构。
Agent 需要的并不只是更多 tool。
它需要一个已经把“这项工作是什么，以及在什么边界内可以怎样完成”表达清楚的环境。
结语：从流程节点，回到业务如何被持续完成
如果沿着这条线回头看，所谓“Agent 会不会消灭 workflow”其实已经不是最重要的问题。
有些流程确实会消失，因为它们只是传统软件能力有限时留下来的操作编排；有些节点也会被重新组合，因为 Agent 不再需要严格沿着人为规定的页面和步骤工作。但那些节点原本承载的业务依赖、判断要求和治理边界，并不会因为路径被拆掉而一起消失。
真正发生的变化，是我们不能再满足于用流程顺序来间接表达它们。
一条流程告诉我们“接下来轮到谁”，却不一定说明这个主体为什么要介入、针对什么对象承担什么责任、依据什么信息作出判断，又被允许改变什么。过去人可以用经验补全这些含义，Agent 越进入真实业务，这些隐含结构就越需要被显式定义。
于是，workflow 被拆掉以后，最后留下来的并不是一个孤立的 Action Space，而是一个更接近业务本身的问题：
企业需要持续完成哪些职能，这些职能围绕什么对象运行，遵循什么规则，又可以由哪些 Actor 在什么边界内承接？
当这些定义足够清楚，具体路径才真正有条件变得灵活。今天由人按照固定流程完成的工作，明天可能由人、系统和 Agent 重新分工；同一项职能内部，也可以根据环境状态动态选择不同路径。
所以 Agent-native 并不是从 workflow 走向“没有结构”，而更像是从预先规定执行路径，走向定义可执行职能，再让 Actor 在边界内自主行动。
这可能也是 Agent 真正进入企业以后，对现有软件和组织方式更深的一次倒逼：我们终于需要把“流程怎么走”背后那件一直没有被充分数字化的事说清楚——
业务究竟是如何被持续完成的。
而当这些职能、对象和行动边界已经能够被环境稳定表达以后，下一个问题才是 Agent 如何持续接入这个环境、维持自身状态并完成长周期行动。这个问题在《把 Agent Harness 放回数字化背景中理解》中继续展开。