企业走向AI原生，真正应该建设的是什么？丨ANC重新理解AI原生建设

一家企业决定加大 AI 投入以后，很快会遇到一个具体问题：今年到底建什么。

答案通常差不多。销售部门要一个销售 Agent，客服部门要一个客服 Agent；也可以从任务入手，把报价、合同审核、投诉分析自动化；再进一步，企业会讨论 AI 能不能承担一个岗位的部分工作，或者把一整条业务流程改造成由 Agent 执行。

微软目前的 Agent Library 里，有面向客户信息、内部政策、请求处理等不同业务场景的 Agent 模板；Salesforce 也提供专门处理服务场景的 Agentforce Service Agent。对产品供应商来说，按职能、场景和任务组织 Agent 非常自然。企业也很容易按照同样的方式开始规划自己的 AI 项目。

但企业还要回答另一件事：这些系统建完以后，公司究竟多了一项什么样的价值创造能力？

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

公司已经意识到，影响长期利润的不只是客服工单处理得有多快。更关键的是，客户会不会持续购买备件、续签维保和服务合同。于是它准备优先解决客户流失问题。

最直接的方案，是做一个“客户成功 Agent”。它可以接入客户关系管理系统、合同、服务记录和邮件，定期找出可能流失的客户，给客户经理推荐下一步动作。

但如果名单出来以后，仍然由客户经理判断先找谁、采取什么措施；措施执行以后发生了什么，也还是由客户经理决定下一步，那么持续推进“降低客户流失”这件事的仍然是人。

按照ANC前面建立的分界，这个系统虽然名为“客户成功Agent”，在这里仍然只是一个AI Tool。

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

一｜Agent、任务、岗位和流程，都是很自然的建设起点

企业今天规划 AI，基本离不开几种说法。

“做一个销售 Agent”，说的是要建设什么系统。

“让 AI 判断哪些客户可能流失”，说的是要完成什么任务。

“让 AI 承担客户成功经理的一部分工作”，说的是人的职责重新分配给AI。

“把续约流程 Agent 化”，说的是现有业务怎样运行。

它们是企业规划AI建设时几种很自然的切分单位。

Agent 是技术系统。

任务是一次具体工作。

岗位是职责组合。

流程是工作之间的衔接方式。

如果企业只是希望把 AI 接入现有的工作，这些边界已经足够实用。

但如果企业准备进一步让 AI Agency 持续主动参与价值创造，就需要确认另一层：

这些现有边界，是否也应该成为 AI Agency 的职责边界？

二｜Agent回答系统是什么，没有回答公司让它长期负责什么

Agent 首先是一个技术载体。

它可以有模型、指令、知识、记忆、工具和系统接口，可以读取数据，可以调用其他系统，也可以连续执行多个动作。

这些能力决定了一个 Agent 能做什么。

但同样的技术结构，可以被放进完全不同的业务里。

一个能够读取客户资料、发送消息并持续调用工具的 Agent，可以用来跟进销售线索，也可以用来处理客户服务，还可以用来催收应收账款。

反过来也一样。

降低客户流失这一个目标，可能同时需要风险识别模型、客户沟通 Agent、普通规则系统、客户关系管理系统，以及客户经理处理重大例外。

企业没有理由要求这样一项经营职责必须被装进一个 Agent 里。

因此，数清楚企业上线了多少个 Agent，并不能告诉管理层，公司究竟把多少价值创造职责交给了 AI。

一个 Agent 很复杂，也可能只负责一段很窄的工作；几个 Agent 加在一起，也可能共同服务同一件工作。

这也是为什么产品目录可以从 Agent 开始，企业的 AI 原生建设却不能停在Agent。

供应商必须把产品做成企业容易购买、部署和理解的形态。销售、客服、财务、IT，本来就是很自然的商品分类。

但供应商不知道一家工业设备公司最重要的是客户留存，还是备件毛利；也不知道另一家公司此刻最需要解决的是库存周转，还是销售增长。

产品目录可以告诉公司有哪些 Agent 能买。它无法替公司决定应该让 AI 长期承担什么经营职责。

三｜任务、岗位和流程，通常继承了现有工作的切法

如果不从 Agent 出发，企业通常会往现有工作流程里寻找。

最容易找到的是任务。

判断客户风险、生成报价、回复邮件、整理会议纪要，都有比较明确的输入和输出，AI 很容易接进去。

但一次任务天然只能截取工作的一部分。风险名单生成以后，客户要不要联系；联系以后对方没有回应怎么办；客户说价格太高，是调整价格、增加服务，还是先解决过去的投诉——这些都已经超出了“判断流失风险”本身。

任务完成了，不等于经营目标完成了。

过去，负责把这些零散工作持续接起来的通常是岗位。

客户成功经理既维护客户关系，也收集信息、作出判断、协调资源、跟进续约和处理异常。

这些工作被装进同一个岗位，并不意味着它们天然应该永远绑在一起。

一个重要原因是，传统企业需要一个人持续负责跨时间、跨系统、跨事件的工作。

AI 进入以后，岗位仍然会存在。但企业没有必要进一步假设：Human 岗位过去怎样打包，AI 的职责以后也必须怎样打包。

流程也是如此。现实业务流程里，有真正创造客户价值的动作，也有大量为了让现有组织能够协作而形成的动作：部门之间传递信息，员工把数据从一个系统录到另一个系统，经理确认以后再交给下一个岗位。

如果其中一部分判断和行动开始由 AI Agency 连续负责，公司就需要重新确认：哪些环节是价值本身需要的，哪些环节主要来自现有组织的交接方式–这部分工作对于AI并不是必要的。

把AI接进每一个原有步骤，原有流程当然可以运行得更快。但一个运行得更快的旧流程，不一定就是 AI Agency 最合理的运行边界。

Agent、任务、岗位和流程看起来是四种不同的东西。它们真正共同的问题是：企业很容易直接继承现有系统和工作结构的边界，再把 AI 引入进去。

而这些边界，是为了过去的组织方式形成的，并不是为 AI Agency 天然准备好的。

四｜如果不从旧工作结构开始，应该从哪里重新切

换一个起点来看客户流失，事情会完全不同。

不先问应该做什么 Agent，也不先问客户成功经理哪些工作可以交给 AI。

先问一件更基础的事：

公司今天究竟怎样把“降低客户流失”这件事持续往前推进？

首先需要发现，客户的备件订单开始减少。

发现以后，要结合服务记录、合同状态、联系人变化判断发生了什么。

判断以后，要决定这次应该主动拜访、解决服务问题、调整商业方案，还是暂时不动作。

采取行动以后，还要知道客户有没有回应，风险有没有变化，原来的判断是否需要调整。

发现、判断、行动、结果，再到下一步。

这里描述的不是一套固定实施流程。

它只是把一件经营上的事情怎样持续向前运行重新展开。

从这个视角出发，公司不需要预设最后一定建设一个 Agent、几个 Agent，也不需要预设原有岗位和流程必须被保留或者删除。

如果公司判断，这件事主要应该继续由客户经理推进，那么 AI 可以只承担风险识别、信息整理或建议生成。

如果公司进一步考虑让 AI Agency 持续承担其中一部分推进职责，再决定需要哪些 Agent、哪些系统，哪些判断和例外继续交给 Human。

变化发生在建设顺序上。过去很容易先有一个技术或工作对象，再问 AI 能为它做什么。

现在可以先看清一项经营目标怎样被持续推进，再决定 AI Agency 应该在其中承担什么。

五｜真正要建设的，是围绕经营目标运行的价值推进系统

到这里，AI Agency 的建设对象可以正式说清楚了。

AI Agency 的建设对象，不是一个 Agent 或孤立任务，而是一套围绕经营目标运行的价值推进系统。

这里的“系统”，不是指某一个软件系统。

它描述的是一项经营目标怎样被持续推进：下一步怎样形成，行动怎样发生，结果怎样回来，并继续影响后续推进。

Agent 可以是其中的技术载体。

Human 可以继续承担其中的重要判断、例外和责任。

普通软件、规则系统和现有业务系统也都可能继续存在。

真正决定建设边界的，不是它们各自原来的名称，而是这项经营价值怎样被持续推进。

一个很简单的检验，是把项目名称里的“Agent”删掉。

“建设客户成功 Agent”删掉以后，如果团队就说不清自己到底准备持续改变什么经营结果，说明目前真正定义清楚的仍然只是技术载体。

如果删掉以后，团队依然能够明确：

我们准备重新设计高风险客户从被识别、判断、行动到结果返回的整套运行，让客户留存这项经营目标得到持续推进——

那么 Agent 用一个还是几个，反而变成了后面的设计选择。

当企业开始围绕同一项经营目标，把AI的判断、行动和结果读取组织成持续推进的运行关系时，一套AI Agency价值闭环才开始出现。

现在先记住一个分界：

Agent是技术载体，经营目标及其价值推进系统才是AI Agency的建设对象。

ANC视角：AI Agency建设对象

这个分界真正改变的，是企业如何立项。

“做一个销售 Agent”，不再是一个完整的建设定义。

企业还需要回答：它准备持续推进什么经营目标？

一旦这样定义项目，原来的项目边界可能发生变化。

一个原本叫“销售 Agent”的项目，可能需要被拆成几项不同建设，因为线索转化、老客户增购和销售预测并不是同一项需要持续推进的经营职责。

反过来，原本准备分别建设的几个 Agent，也可能属于同一个建设对象，因为它们共同服务的是一项客户续约目标。

项目名称没有必要因此全部改变。

技术团队仍然可以按照 Agent 组织开发，业务团队仍然可以按照任务和流程组织工作。

但管理层需要多一层视角：

公司究竟准备重新设计哪一项经营价值的推进方式。

这也会改变 AI 预算的讨论单位。

预算不再只对应“今年开发几个 Agent”，还需要对应企业准备把哪些经营目标重新设计成可以被 AI 持续推进的价值运行系统。

这样，当技术交付完成的时候，公司至少知道这套系统服务的是哪一项经营目标，以及它在价值推进中承担什么位置，而不只是知道又上线了一个Agent。

AI原生建设不是给旧工作结构装上更多Agent，而是重新决定公司的经营价值如何被持续推进。

写在最后

那家工业设备公司当然仍然可以建设客户成功 Agent。

它也可以先做流失预警，继续让客户经理负责大部分跟进，保留现有的续约流程。这些都是后面的设计选择。

在那之前，公司需要先确认自己究竟围绕什么建设。如果答案是降低客户流失，那么 Agent、任务、岗位和流程都应该围绕这项经营职责重新确定自己的位置，而不是由其中任何一个先替公司划定边界。

找到正确的建设对象，只解决了应该围绕什么设计。还有一个更难的问题没有回答：

一个经营目标很重要，是否就意味着它真的需要AI Agency持续推进？

补充说明

1. Microsoft Learn《Configure and deploy agents from the Agent Library》及《Templates overview in Agent Library in Copilot Agent Kit》。截至 2026 年 7 月更新的官方文档显示，Microsoft Copilot Studio 的 Agent Library 以可部署模板和业务场景组织 Agent，包括 Know Your Customer、Executive Brief、My Company Policy、Request Tracker 等。本篇仅将其作为可观察对象，用于说明企业 Agent 产品确实会自然地按照具体场景、任务和业务需求组织，不采用微软关于 Agent 价值的结论。
2. Salesforce Help《Get to Know Agentforce Service Agent》。Salesforce 将 Agentforce Service Agent 描述为面向服务场景、处理服务任务与客户交互的一类 AI Agent。本篇只用它说明按业务职能组织 Agent 是现实产品市场中合理且常见的方式，不将这一产品分类作为 ANC 定义依据。
3. Microsoft 与 Salesforce 均销售企业 AI 与 Agent 产品，相关官方材料与自身商业利益存在直接关系。因此上述来源只承担“可观察性”，不承担本文论证。删掉两个来源，本文关于 AI Agency 建设对象的定义与推导不变。
4. 文中工业设备公司、客户流失及客户成功 Agent 均为设想场景，延续本栏目第一期的企业背景，不对应具体公司，不含精确数值，也不用于证明“客户流失天然适合 AI Agency”。
5. 本篇未采用 Agent 市场规模、企业 Agent 部署数量、自动化率等行业统计。此类数据能够说明 Agent 正在被采用，却不能回答企业应该把什么定义为 AI Agency 的建设对象，无法承担本篇核心论证。
6. 以下判断由 ANC 提出，不是上述厂商材料的结论：Agent 是技术载体而非经营职责本身；企业现有的任务、岗位和流程边界通常继承既有工作结构；AI Agency 的建设对象是一套围绕经营目标运行的价值推进系统；企业不能让产品目录或既有工作边界替自己定义价值创造的建设对象；Agent 是技术载体，经营目标及其价值推进系统才是 AI Agency 的建设对象。

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

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