企业搭建智能体时，常遇到一个奇怪的现象：同样的业务场景、同样的原始文档，调用同一个基础模型，在不同的智能体平台上搭出的智能体，效果可能差得很远。有的智能体能用，有的只是流程跑通，结果却无法交付。

造成这种差异的，是平台拆解任务、调用企业知识和组织多环节协作的能力，而正是这些能力共同影响智能体最终的可用性。

这也解释了企业智能体正在发生的一次迁移。第一阶段解决的是如何快速搭出一个智能体，让员工通过对话框或工作流完成单点任务；下一阶段要解决的，是智能体如何参与连续流程，并在不同岗位之间共享准确的上下文。前者提升个人效率，后者才可能改变组织的生产方式。

本期，爱分析对话神州数码 AIBG AI 产品部总经理侯浩。我们从不同平台搭建效果为何悬殊聊起，进一步讨论企业智能体进入核心流程时，平台、知识治理和行业经验分别扮演什么角色。

核心观点

同样的场景、文档和基础模型，在不同平台上搭出的智能体仍可能效果悬殊。平台对业务流程和企业知识的处理能力，正在成为可用性的分水岭。

企业智能体只有进入需求、执行、审核和交付组成的连续流程，才能真正影响组织效率。只提升单个岗位的效率，尚未改变组织原有的生产方式，价值就有限。

上一轮信息化留下的数据平台不会失效，但其中的文档、关系和专家经验，需要按具体场景重新组织成模型能够识别、调用和追溯的上下文。

Skill、工具连接和模型接入会逐渐成为平台标配。厂商更深的壁垒，是在足够窄的行业流程中，把专业规则积累成跨企业可复用的 Skill。

AI 项目应该从企业最有价值的核心流程切入。管理层负责选择和推动，企业内部要有人接手运营，厂商则要把流程、知识、模型与原有系统真正接起来。

企业 AI 的拐点取决于知识治理的成熟度。当新的数据和专家反馈能够持续进入系统，智能体才会越用越好，局部提效才可能转化为组织生产力。

以下为本次访谈实录，在不改变原意基础上略有修改。

01

智能体跑通了，为什么还是不能用

爱分析：同样的场景、文档和基础模型，在不同平台上搭出的智能体，效果会差很多，这是什么原因导致的？

侯浩：平台之间真正拉开差距的，往往不是有没有搭建工具，而是能不能把流程和知识处理好。过去很多平台解决的是怎么创建一个智能体、接入一个模型、编排一段工作流，这只是第一步。流程决定平台搭出的智能体在组织里怎样工作，知识决定它面对具体任务时能不能理解企业语境。即使基础模型相同，这两部分做得不一样，最终产物也会很不一样。

传统 ERP、OA 等系统主要记录人和人协同之后产生的数据，并把既有流程搬到线上。智能体带来的变化可能更深，它有机会把一部分人和人的协同，改造成人与智能体、智能体与智能体之间的协同。如果平台只是给每个员工配一个对话框，个人效率可能提高，但组织原来的运转方式并没有发生变化。

以研发为例，研发不是工程师写代码这么简单，它包含需求、编码、评审、提交、测试等多个环节。AI Coding 通常先提升单个工程师的效率，但如果要提升整个研发团队的产出，就要让平台里的智能体进入完整流程：什么时候生成代码，什么时候要求人补充信息，什么时候触发评审和测试，还要把前一环节的结果继续传递下去。

过去工程师晚上十点离开，工作也就停了；如果主要任务由 AI 持续执行，人只在必要节点确认，流程理论上可以继续运转。只有到了这一步，AI 才从个人工具变成流程中的调度和执行力量。

爱分析：你把差异归结为流程和知识。先看流程，具体会怎么变？

侯浩：第一代企业智能体平台，形态比较接近通用聊天产品，再叠加工作流和外部工具连接，用户搭什么流程，系统就跑什么流程，这种形态适合财务分析、招聘辅助这类相对简单、偏个人的场景。

进入组织以后，只靠一个大对话框就不够了，智能体平台得能表达任务、岗位、协作关系，并共享上下文。

比如医学报告写作，它不只有写作，还包括数据补充、审阅和提交。系统要把这些节点分别表达出来，每个节点可能对应一个专业角色和智能体，再把它们放在同一个工作空间里，共享记忆、文档和规则，写完以后按条件触发审阅。

第一代产品不会立刻消失，这更像一次迁移：企业对 AI 的要求从完成一次任务，逐渐变成持续参与一段流程。

爱分析：流程拉长以后，不同智能体还会一直调用同一个模型吗？

侯浩：因为不同任务对效果、速度和成本的要求并不一样，没有必要所有环节都调用同一个高成本模型。

简单任务可能更看重响应速度，用轻量模型就够了；专业翻译、数据分析或复杂推理，可能需要行业模型或能力更强的模型。比如医学翻译里有大量专业术语，通用模型未必最合适，企业可能会用开源模型结合行业数据继续训练。

进入多智能体协同以后，不同智能体调用不同模型会成为常态。

企业需要一层统一的模型管理能力，让上层智能体通过一致的接口调用不同模型。同时，大量跨模型调用会带来上下文和 Token 消耗，系统要能打开每一次调用，看看哪些上下文可以压缩，哪些内容可以省略，哪些结果能够缓存复用。

这里真正要平衡的是效果、速度和成本，而不是单纯追求模型参数更大。模型选得过重，会让很多本来可以低成本完成的任务变贵；选得太轻，最后又可能因为结果不可用而返工。

02

数据都一样，AI 为什么还是用不好

爱分析：流程之外，你反复提到的另一个词是知识，为什么知识这么关键？

侯浩：因为大模型执行任务时，真正依赖的是上下文。不同智能体只有拿到一致、有效的上下文，才能在同一流程里做出相互衔接的结果。代码、设计文档、评审记录、业务数据和专家意见如果仍然彼此分散，后一个智能体就不知道前一个环节发生了什么，也很难延续组织已经形成的判断。

所以我们谈智能体记忆，放到企业里其实就是上下文。企业需要处理的内容远比数据库字段复杂。大量业务知识散落在文档、图像和现场记录中，平台需要先对它们进行拆解和关联，再交给模型使用，同时保留追溯来源的能力。人看一篇完整 Word 最舒服，模型未必，它需要的是另一种组织方式。

爱分析：不少企业前几年已经建过数据中台和知识库，现在再做一遍，区别到底在哪里？

侯浩：两者首先是服务对象不同。传统数据平台和知识库主要面向员工与业务系统，设计重点是人怎么查看文档、怎么管理权限、怎么查询结构化数据，而面向 AI 的知识体系，首先要让模型读懂和调用，最终形态甚至可能是 JSON、向量或关系结构。

建设方式也不同。过去容易先立项建设一个覆盖全公司的平台，再让各业务寻找使用方式，而面向 AI 的知识治理更适合由场景驱动。企业先确定要改造的核心流程，再处理这个流程真正需要的知识。做医学报告，就先治理报告写作、实验数据和文献溯源所需的内容，而不是一次性把企业上千个场景的数据全部处理完。

这样做还有一个现实原因：企业里真正有用的数据分散在不同系统和岗位手里，脱离场景先做全量治理，很容易花了很多钱，却不知道哪些数据会进入模型、影响哪一个结果。

当然，这不是要推翻原有系统。ERP、数据仓库以及行业业务系统仍然承载交易与运营数据，新的 AI 系统更像是在原有系统之外建立一套面向模型的生产力体系，把现有系统中的信息抽取出来，以大模型可用的方式重新组织。所以，它们是衔接关系，不是简单的替代关系。

爱分析：如果面向模型重新组织知识，把文档切片、做向量化就够了吗？

侯浩：远远不够。文档切分只是第一层，接下来还要建立对象之间的关系，例如药品与靶点、实验数据与报告结论、论文与引用来源之间的联系。

再往下，真正有价值的是专家经验。一份医学报告写完，审阅者指出某一章为什么不能这样写，系统不能只改这一次，还要把这条意见沉淀下来，在下一次遇到相似情况时重新调用，否则专家会一直纠正同一个问题，智能体也不会越用越好。

03 

组件广场很热闹，真正的壁垒却藏在细分流程里

爱分析：现在很多平台都在建 Skill 广场、接各种组件。这些资产真的能形成壁垒吗？

侯浩：数量本身很难形成长期壁垒。Skill 管理、工具连接、智能体运行、知识加载和模型接入，都会逐渐变成平台的通用底座。真正能拉开差距的，是厂商能不能进到一个足够具体的行业流程里，把规则和专业知识做成可以重复使用的产品。

医药、制造都太大了，厂商不可能把所有流程都做完，只能继续缩小，比如做到创新药企的医学写作、制造企业的工艺改良。

以临床研究报告为例，一份报告有固定章节和审计要求，既要引用公开文献，也要分析企业自己的实验数据。抓取文献、统计实验数据、生成某一章节，都可以继续拆成更小的能力。

某项能力如果只在一个项目里用一次，还是定制服务；如果几百家同类企业都会用，它才可能沉淀为 Skill。一个场景需要 100 种能力，平台已经积累了 80 种，后来者再去追平或者超越的成本自然会更高。

爱分析：智能体平台的 Skill、专家智能体和工作空间，三者区别是什么？

侯浩：它们是三个层级：Skill 对应技能，专家智能体对应岗位，工作空间对应业务流程。

还是以临床研究报告为例，从公共文献中抓取数据可以是一项 Skill，对企业实验数据做统计分析也可以是一项 Skill；多项 Skill 组合起来，形成医学写作智能体；写作、审阅、数据补充等多个专家智能体，再组成医学写作的工作空间。

跨企业最容易复用的通常是 Skill，而专家智能体带有更强的企业特征，因为同一个岗位在不同企业，使用的模板、数据、审批标准和责任边界都可能不同。

爱分析：平台交付以后还要长期处理流程和知识，传统实施的方式需要改变吗？

侯浩：需要。企业智能体不是交付一套标准软件就结束。复杂场景要把业务流程、知识、模型和原有系统接在一起。厂商需要既懂产品和技术、又能进入业务现场的人，帮助企业识别流程节点、治理数据，并把系统真正运转起来。

很多 AI 项目能完成部署和演示，最后却进不了日常运营，常常不是少了某个功能，而是没人持续处理业务变化、专家反馈和知识更新。企业自己也要有人接手，从接手系统、参与运行，到最后能够维护和优化场景。如果还是列功能、采购、实施、验收那套逻辑，项目交付了，AI 的价值也可能跟着停下来。

04 

企业 AI 不会突然爆发，拐点要等知识真正转起来

爱分析：厂商驻场服务之前，企业自己要做哪些准备？先从什么场景开始？

侯浩：我比较建议从企业最核心、最有价值的流程切入，而不是只挑最容易展示效果的办公场景。当然，核心场景往往也最难做。如果只要求三个月看效果，大家一般会选择先做知识问答、办公助手，它们可以验证技术，但不一定碰到企业真正的生产力。

比如一家药企真正的核心可能是营销或研发，一家分销企业可能更重视风控，这些流程很难靠一个通用助手解决。管理层要看业务价值、组织影响和长期投入，还要推动跨部门协同，所以这件事通常得是一把手工程。

另外，企业要配置既懂业务又理解 AI 的人，能够在厂商离场后接手，还要提前盘点哪些数据真正影响模型表现。厂商可以提供工具和方法，但不可能一上来比企业更清楚关键数据在哪里。双方都得准备好，项目才可能从一次性交付变成持续运营。

爱分析：前面提到，智能体需要进入完整业务流程。再往前走，AI 原生流程可能会呈现什么形态？

侯浩：目前还没有标准答案，我们看到的至少有两条路径。

第一条是给流程里的每个岗位配一个专家智能体，让不同人的智能体相互交流。比如今天这场多人访谈，未来可能先由每个人的智能体交换信息、整理纪要，我们各自花十分钟审核它有没有准确表达自己的观点。

第二条是多个岗位共用一个智能体。它掌握团队共享的上下文，接收不同岗位的指令，再去调用其他智能体或 Skill 完成写作、审阅、溯源和测试任务。医学报告可以由一个共享智能体服务写作者、审阅者和统计人员；研发团队也可以由一个总智能体调度代码生成、评审和自动化测试。

我们现在更偏向验证第一条，因为它与现有岗位结构更接近，切入成本低一些。第二条会把一个人操作多个智能体，变成多个人共同驱动一个智能体，权限、责任和决策机制都会更复杂，目前还在设计和验证。

爱分析：如果流程形态还在探索，企业智能体产业离真正的拐点还有多远？

侯浩：不会那么快。企业 AI 不是某个工具升级，它会牵动业务形态、商业模式和组织结构，只能从一个流程、一个场景慢慢渗透。现在多数企业还在挑一两个场景验证，整个行业仍然很早期。

我更关注企业知识准备到了什么程度。知识没有治理到可用状态，幻觉、结果不稳定和无法追溯就很难解决，而且知识治理不能做完一个项目就停，新文档、新数据、对象关系和专家反馈要持续进入体系。

等这件事成为企业的日常运营，智能体每做一次任务都能沉淀新的上下文，专家每改一次都能影响下一次执行，飞轮才真正转起来。那个时候，企业 AI 才可能从局部提效进入组织生产力的持续增长。

注：点击左下角" 阅读原文 "，查看更多洞察内容。