什么样的业务，才真的需要AI Agency？丨ANC重新理解AI原生建设

上一篇留下了一个问题。

企业已经不再只围绕一个 Agent、一项任务或者一条现有流程定义 AI 建设，而是开始回到经营目标，重新看一项价值怎样被持续推进。

但找到正确的建设对象，不等于找到了正确的推进角色。

一个经营目标很重要，也不意味着它就需要 AI Agency。

继续看那家工业设备公司。

公司准备提高客户续约率，可以建设一套自动运行的续约系统。

合同到期前 90 天，系统发送第一次提醒；60 天仍未确认，就在客户关系管理系统里创建销售任务；到期前 30 天，自动升级给销售经理；如果合同金额超过一定范围，再进入 Human 审批。

这套系统可以跨越合同、客户关系管理、邮件和审批系统，连续运行几个月，自动完成很多步骤。AI 也可以参与生成邮件、整理客户资料和选择沟通模板。

它看起来很像一个 Agent。

公司也可以建设另一套系统。

这套系统没有一条固定的续约路径。它发现某个客户的备件订单开始减少以后，需要结合服务记录、联系人变化和合同状态判断发生了什么，再决定是先解决投诉、安排拜访、调整服务方案，还是暂时不采取行动。

客户回应以后，原来的判断可能失效，下一步需要重新形成。

第二套系统的显性步骤未必比第一套更多。

那么，哪一种业务真正需要 Agency？

答案不在系统能自动运行多少步。

而在于每一步完成以后，下一步究竟是如何确定的。

NotebookLM的音视频概览，解读的比较通俗易懂，对于时间比较紧张的读者朋友，可以听听，会有启发。

一｜企业为什么容易把技术复杂度当作Agency信号

今天企业识别 Agent 场景时，最容易看到的是一些显性的技术特征。

工作需要连续完成多个步骤。

系统需要调用多个工具。

过程跨越多个业务系统。

大模型需要参与判断和生成。

系统还可以在较少 Human 介入的情况下自动运行。

这些能力让 Agent 与过去只能回答问题的 AI 应用显得很不一样。市场上的产品语言也进一步强化了这种印象。

自动审核合同、生成报价、处理报销、回复客户、安排库存、跟进销售线索和催收欠款，都可能被归入 Agent 场景。它们表面上都有多步骤、工具调用、跨系统和自动执行。

于是企业很自然地形成一种判断：

工作越复杂，越应该使用 Agent。

但一套合同审核系统可以读取合同、提取条款、比对规则、标记风险，再把特定合同送交法务。整个过程很长，也可以使用大模型，但每种结果接下来进入哪里，已经被提前规定。

另一项销售跟进工作，显性步骤可能只有识别情况、采取行动和读取结果。可客户状态不断变化，任何一次回应都可能改变原来的推进路径。

这两项工作的区别，不能只用步骤多少或者系统复杂度来解释。

微软在 Agent Framework 文档中同样把“多步骤”同时放在 Agent 和 Workflow 的范围内：Workflow 的执行流可以被显式定义，也可以包含条件路由、循环和动态执行路径；Agent 的步骤则通常由模型根据情境和可用工具决定。这至少说明，在现实产品体系中，多步骤和复杂控制流本身不能完成二者的分界。

技术特征能够说明系统怎样运行。但企业还需要追问另一层：在这项经营目标的推进中，究竟是谁在形成下一步？

二｜多步骤自动化和Agency，差在下一步怎样产生

为了看清这条分界，可以先把两种典型的推进结构分开。

第一种结构里，推进逻辑主要在运行以前形成。

发生什么事件，进入哪个节点；得到什么结果，触发哪一个分支；什么条件下循环、暂停、升级或者结束，都由规则、流程图或者程序逻辑预先定义。

系统运行时当然会遇到不同情况。

它可以拥有几十个条件分支，可以调用多个系统，也可以让大模型在某个节点完成分类、摘要、生成或者一次判断。

执行路径甚至可以根据运行数据动态变化。

但这些变化发生在一套已经定义的控制结构里。当前步骤完成以后，下一步主要仍然由预设逻辑决定。

这更接近一种以预定义控制流为主体的 Workflow 结构。

第二种结构里，企业可以提前定义经营目标、可用工具和必要边界，却无法把主要推进路径完整写出来。

系统采取一次行动以后，需要重新理解当前局面。

新的信息可能改变之前的判断，行动结果也可能让原来的路径失效。系统需要根据当时的情况决定：继续原来的方向、换一种行动、获取更多信息、等待、停止，还是交给 Human。

这时，下一步不再只是从既定流程中被触发。

它需要在运行中持续形成。

Amazon Bedrock Agents 的公开运行说明展示了一种可观察的技术形态：系统解释当前输入、选择行动或查询知识、读取行动产生的结果，再判断是否需要继续编排。这里引用它不是为了采用 AWS 对 Agent 的定义，而是为了说明“行动结果重新进入下一轮判断”已经是现实 Agent 产品中的运行方式。

这两种典型结构不是非此即彼。

现实系统完全可以把确定性环节交给 Workflow，把需要持续判断的环节交给 AI Agency，再由 Human 处理关键决定。它们可以共同存在于同一个价值推进系统里。

真正需要区分的是，当前这部分经营职责主要依靠什么向前运行：

第一种主要执行已经形成的控制逻辑。
第二种在运行中持续形成推进路径。

Agency可以有规则，也必须受到边界约束。

它承担的不是工作流无法处理异常时的补位职责。

Agency承担的是：当经营目标需要继续推进，而下一步不能主要由预设路径决定时，根据当时的情境与行动结果继续形成下一步。

因此：

连续执行，不等于持续形成下一步。

三｜同一个客户续约目标，可以有两种不同的运行结构

回到工业设备公司的客户续约。

第一套系统解决的是到期提醒。

它的基本路径可以提前写出来：

合同进入到期前 90 天，发送提醒。

60 天仍未确认，创建销售任务。

到期前 30 天，升级给经理。

达到特定金额，进入 Human 审批。

如果客户完成续约，流程结束。

这条路径可以很长。

系统可以读取合同数据库，调用客户关系管理系统，自动发送邮件，生成续约材料，还可以根据客户所属行业选择不同模板。

但无论系统完成多少动作，持续推进的逻辑主要来自企业事先设定的时间、状态和规则。

AI在这套系统里很有价值。

它可以减少人工操作，提高信息处理和内容生成效率。整套系统也可能是一项非常好的自动化建设。

只是公司不必因为它可以连续运行很多步，就认定自己需要 AI Agency。

第二套系统面对的不是“按时完成续约提醒”，而是持续降低高价值客户流失。

客户的状态不会按照一张统一时间表变化。

有的客户订单减少，是因为设备进入季节性停产。

有的客户投诉增加，是因为长期没有解决的服务问题。

有的客户正在测试竞品，有的只是更换了采购负责人，还有的对价格敏感，却依然认可产品和服务。

发现风险以后，系统不能把所有客户送入同一套动作。

它需要理解当前客户为什么发生变化，检查此前已经采取过什么措施，再决定此时更适合安排服务、联系新的负责人、准备商业方案，还是继续观察。

行动之后，客户可能接受，也可能拒绝；可能暴露出新的问题，也可能让风险判断发生变化。

于是，下一步必须再次形成。

在第一套系统里，客户没有确认续约，触发的是预先定义的销售任务。

在第二套系统里，客户没有回应，只是一个新的情境。它不足以直接决定下一步，还需要和客户状态、历史行动及当前结果放在一起重新判断。

两套系统都服务客户续约，都可以被命名为客户成功 Agent。

但业务名称、Agent 名称和工具数量，都没有决定它们是否需要 Agency。

真正产生差异的是：

到了下一刻，系统是在继续执行预设的推进逻辑，还是需要根据新的局面重新决定怎样推进目标。

这也不是在证明客户流失天然适合 AI Agency。

一家公司的客户数量、业务模式和实际运行方式不同，完全可能得到不同结论。

这个对照只说明一件事：

Agency的分界发生在下一步如何形成，而不是一条流程总共有几步。

四｜企业真正要识别的，是复杂发生在哪里

复杂业务并不是只有一种复杂。

一种复杂，来自已经能够描述的结构。

规则很多，分支很多，涉及的系统很多，工程实现也很困难。

例如一套跨地区费用系统，需要识别员工所属公司、费用类型、金额范围、税务要求和审批层级，再根据不同结果进入报销、补充材料、复核或者拒绝。

它可能包含数百条规则和大量例外，也可能使用大模型读取票据、识别费用说明。

这是一项很复杂的建设。

但只要主要情况仍然能够被规则、条件和流程稳定描述，它的核心困难就是如何把已经知道的运行逻辑准确实现。

另一种复杂，来自经营局面本身不能被提前展开。

企业采取行动以后，对象的状态发生变化；新的信息改变了原来的判断；同一个结果出现在不同情境中，需要产生不同的下一步。

此时，困难不只是系统要处理多少规则。

而是企业在运行以前无法完整知道，目标将经过怎样的路径被推进。

前一种复杂主要增加工程实现难度。

后一种复杂开始产生持续形成下一步的角色需要。

两者在系统表面可能非常相似。

它们都可以多步骤、跨系统、调用大模型，也都可以高度自动化。但这些可见特征只说明系统规模和技术能力，没有说明推进逻辑来自哪里。

如果企业把两种复杂混在一起，就容易同时犯两种错误。

一方面，它可能把能够通过稳定控制逻辑处理的业务做成开放式 Agent。

另一方面，它也可能把真正依赖持续判断的经营目标压进固定工作流，用不断增加规则和分支的方式应对本来无法预先穷尽的局面。

因此，复杂度本身不是一个足够准确的 Agency 指标。

企业真正要识别的，不是工作表面有多复杂，而是：

复杂发生在哪里。

如果复杂主要来自可以被描述的规则、步骤和系统关系，确定性软件、规则系统和 Workflow 仍然可以承担主要推进。

如果复杂来自情境持续变化，并且行动结果不断改变对下一步的判断，Agency才开始进入视野。

Agency是一种目标推进结构，不是一种技术复杂度等级。

五｜什么时候Agency才值得进入讨论

到这里，企业可以获得一个更严格的 Agency 入口。

当一项经营目标无法主要依靠预定义路径推进，而必须根据不断变化的情境与行动结果持续重新形成下一步时，企业才真正有理由讨论Agency。

这里的关键词是“有理由讨论”。

它不是在说，只要业务会变化，企业就应该建设 AI Agency。

现实中的所有业务都会发生变化。Workflow也可以用条件路由处理变化，可以暂停运行，可以在特定情况下进入另一套机制。

真正需要判断的是，预定义控制逻辑能不能承担这项经营目标的主要推进。

如果大部分常态情况都有稳定做法，只在少数例外中需要重新判断，企业通常没有必要因此把整个业务改造成 Agency 结构。

如果大多数关键时刻都不能从预设逻辑直接得到下一步，而且新的情境与行动结果不断改变推进方向，那么持续形成下一步就不再是偶发例外，而成为这项业务本身的需要。

这时，Agency开始具有结构价值。不是工作越复杂越需要Agency，而是目标越需要在变化中持续形成下一步，Agency越可能具有价值。

ANC视角：AI Agency适用性

当团队说：

我们准备把这条流程 Agent 化。

管理层需要先问：

这条流程里，真正需要系统持续重新形成下一步的地方在哪里？

如果团队能够提前描述主要推进逻辑，说明不同结果接下来进入哪个节点，那么企业首先得到的是一个 Workflow 或自动化候选项目。

Agent仍然可以被用在其中，但不必因此把整条流程定义为 Agency 建设。

当团队说：

这个 Agent 已经可以自动跑完整个流程。

企业还要确认：

推进路径是系统根据当时局面持续形成的，还是建设团队已经把主要控制逻辑提前定义好了？

全自动只能说明 Human 没有在执行阶段持续介入。

它不能说明下一步是怎样产生的。

这会让项目边界变得更准确。

同一项业务里，能够提前确定的部分可以继续使用规则、软件和 Workflow；真正需要根据情境持续形成下一步的部分，再作为 Agency 候选范围。

企业不需要在“全部做成 Agent”和“全部保留 Workflow”之间二选一。

确定性软件、AI Tool、Workflow、AI Agency和Human Agency可以同时存在。它们承担不同角色，共同服务同一个经营目标。

管理层需要避免的是，仅仅因为 AI 能够自动运行，就把一项工作升级成 Agency 建设。

只有当持续形成下一步本身成为业务需要，Agency才开始有价值。

写在最后

那家工业设备公司不需要在两套续约系统之间选择谁更“高级”。

到期提醒适合以预定义控制流为主体的 Workflow，并不代表它的价值较低。

恰恰相反，如果主要推进逻辑已经清楚，企业就应该让系统稳定、透明地执行，而不是为了使用 Agent，重新增加不必要的判断。

降低高价值客户流失可能需要另一种结构。

当客户状态、历史行动和最新结果不断改变推进方向时，公司才有理由进一步讨论：是否需要一个 Agency持续接住这项经营目标。

经营目标及其价值推进系统，是 AI Agency 应该围绕的建设对象。但只有当这个目标需要在变化中持续形成下一步，Agency才可能成为合适的推进角色。

到这里，企业找到了值得继续判断的候选目标。下一步还有一个更具体的问题：即使一个目标确实需要Agency，它又要被定义到什么程度，AI才能真正开始推进？

来源与限制

1. Microsoft Learn《Microsoft Agent Framework Workflows》。该文档指出，Agent与Workflow都可以包含多个步骤；Workflow的执行流被显式定义，同时可以包含条件路由、循环和动态执行路径；Agent采取的步骤则通常根据情境和可用工具产生。本篇仅将它作为可观察对象，用于说明“多步骤”和“动态路径”都不是区分Agency的充分条件，不采用微软的产品定义作为ANC的经营分界。
2. Amazon Web Services《How Amazon Bedrock Agents works》。该文档描述了Bedrock Agent在运行中解释输入、选择行动或知识查询、读取行动结果，再判断是否继续编排的过程。截至2026年8月，该页面同时注明原Bedrock Agents已转为Bedrock Agents Classic并停止接受新客户。本篇只使用其公开运行机制作为观察，不对该产品作采购建议，也不将AWS的Agent定义作为ANC依据。
3. Microsoft与AWS均销售企业AI、云计算及Agent相关产品，官方文档与自身产品体系存在直接商业关系。因此两个来源只承担“市场上确实存在以预定义控制流为主体的Workflow与在运行中形成步骤的Agent结构”的可观察性，不承担本文核心论证。删掉两个来源，本文的判断轴仍然成立。
4. 文中的工业设备公司、续约提醒规则、客户状态及留存推进系统均为设想场景，延续本栏目前两期的企业背景，不对应具体公司。它们只用于对比两种典型运行结构，不用于证明客户续约或客户流失天然适合AI Agency。
5. 本篇未使用Agent市场规模、企业自动化率、模型能力排名或项目ROI等统计。这些数据能够说明技术采用与能力变化，却不能回答一项经营目标的下一步究竟如何产生，因而无法承担本篇的核心判断。
6. 以下判断由ANC提出，不是上述厂商材料的结论：连续执行不等于持续形成下一步；Agency是一种目标推进结构，而不是技术复杂度等级；经营目标重要不代表它需要Agency；只有当目标必须根据变化的情境与行动结果持续形成下一步时，企业才有理由讨论Agency；这项判断只是Agency可能具有价值的入口，不等于企业应该采用AI Agency。

感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：
「塔迪AI工程系列」FDE落地工程、ANC：AI Native Company未来公司系列、GEO、AI判断工程。
「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。