Agent真正进入业务后，最难的不是模型也不是文档，而是任务背后的知识建模

文/田志刚 （微信号：511956894）

——要让Agent达到专家水平，先要给它专家级的数据、信息和知识基础

大模型刚开始进入企业的时候，AI应用相对简单。很多项目本质上是问答型应用：用户提出问题，系统从知识库中找到相关内容，再由大模型组织生成答案。

在这种模式下，核心工作主要是把已有资料整理好、切分好、向量化，再做好检索和生成。因为其主要价值是提供参考、辅助查询和启发思路，所以相对容易落地，企业对准确性和业务闭环的要求也没有那么高。

但现在，企业对Agent的期待已经明显变化。越来越多企业希望Agent真正进入业务，去完成需求识别、方案推荐、风险判断、异常处理、流程推进、决策辅助、系统操作，甚至直接采取行动。

也就是说，Agent正在从“查资料、答问题”，走向关联、判断、分析、推理和行动。

而企业让Agent进入真实业务，当然不是希望它只是机械复制普通员工当前的工作方式，更不是接受它继续重复人工中已有的各种遗漏、误判和服务不一致。企业真正期待的是：Agent能够稳定达到甚至接近优秀员工和业务专家的水平，把高质量能力规模化。

让计算机系统获得专家级知识并支持甚至模拟专家解决复杂问题，并不是一个新命题。早期专家系统、知识工程以及后来的认知心理学的研究分析，都围绕如何获取、表示和使用专家知识展开。Agent时代只是把这个问题重新推到了企业核心业务中。

如果希望Agent达到专家水平，就不能只给它普通水平的数据、信息和文档，而必须把专家完成任务所依赖的数据、信息需求和知识逻辑分析出来。换句话说：Agent要实现专家级输出，前提是先获得专家级输入。

这里最关键的是两类过去主要依靠人自然完成、今天却必须显性化的知识：第一类告诉AI“为了把这个任务做好，到底应该看什么”，这个是Agent中上下文工程的前置工作；第二类告诉AI“拿到这些信息以后，应该怎样理解、判断和行动”，这类知识通常不在现有的文档中系统的保存。

一、Agent进入业务后，难点已经变了

假设一家电信企业希望建设一个从客户咨询、产品推荐、购买到后续服务的一体化Agent。

企业并不缺资料。客服知识库中已经有产品手册、套餐说明、促销政策、办理流程和常见问题；企业内部还有CRM、计费系统、订单系统和客服系统。需要的模型可以买，RAG可以搭，API也能接。

客户问：“我现在每个月话费有点高，能不能帮我换一个更合适的套餐？”

如果只是过去那种问答型应用，这个问题并不难。系统可以马上告诉客户套餐A多少钱、套餐B有多少流量、套餐C包含哪些权益。

但如果希望Agent真正完成一次靠谱的产品推荐，就完全不一样了。它首先必须知道：客户现在是什么套餐？过去几个月实际用了多少流量、通话和增值业务？有没有家庭成员共享？是否已经绑定宽带？合约还有多久？当前享受什么优惠？过去有没有投诉或服务异常？客户所在区域网络情况如何？之前和客户沟通过什么？客户所谓“贵”，到底是套餐月租高，还是家庭整体通信成本高？

然后，即使这些信息都拿到了，Agent仍然要继续判断：客户是真的需要降档吗？是不是更适合家庭融合套餐？某个产品虽然能办，但是否真的适合？是不是应该先处理已有投诉，而不是继续销售？什么情况下可以自动推荐？什么情况下必须转人工？

所以，Agent从问答走向业务执行以后，真正的难点已经不是“有没有资料”，而是企业有没有把任务背后的两类关键知识分析清楚。

二、第一类关键知识：专家知道“该看什么”

很多人一谈上下文，就想到把更多数据塞进Prompt，比如把CRM里的客户信息取出来、把ERP里的订单数据取出来、把历史对话放进去。但真正更前置的问题是：为什么要取这些信息？这些信息是不是全面？有没有遗漏？哪些信息真正影响判断？

也就是说，为了完成一个任务，到底应该获取哪些信息，这本身就是一类重要知识。可以把它叫做“信息需求知识”。它不是实际信息本身，而是关于“该获取什么信息”的知识。

消防救援是一个很典型的例子。专业消防人员到达现场以后，会主动观察烟的颜色和浓度、风向、建筑结构、起火位置、人员分布、可燃物类型和进出通道。普通人也站在同一个现场，这些信息客观上同样存在，但普通人往往只看到“冒烟了”“着火了”。他并不知道哪些信息应该看、为什么要看、什么信息更重要、什么信息发生变化以后意味着风险改变。

层次	消防场景	电信销售场景
专家级信息需求知识	需要观察烟色、风向、建筑结构、人员位置、可燃物等	需要获取套餐、消费、流量、合约、家庭关系、投诉、历史沟通等
实际上下文信息	黑烟、东北风、钢混结构、三层有人被困	当前套餐159元、月均流量25GB、合约剩2个月、有家庭宽带

真正区分普通人与专家的，首先不是“看到的信息不同”，而是专家知道应该主动去看什么。专家和普通人的差距，首先就体现在“看什么”上。

所以，对Agent来说，真正需要的不是一般性的上下文，而是专家级的信息需求知识。只有先把专家在不同任务和判断节点上“应该看什么”分析出来，后续的数据接入和上下文工程才有明确目标。

否则，企业即使接入再多系统，Agent也可能只是“看见很多数据，却没有看见关键数据”。

过去的知识管理更多管理产品、制度、流程、SOP和培训资料，很少有人专门去建设“完成某个任务到底需要获取哪些信息”。但Agent必须显式拥有这一层，因为AI不会天然知道“这个时候应该看什么”。

三、第二类关键知识：专家知道“看完以后怎么判断”

即使Agent已经拿到了正确、全面的信息，它仍然不一定能完成任务。比如，它已经知道客户当前套餐159元、过去半年平均使用25GB流量、合约还有2个月、家里已有宽带、最近两次都表达费用偏高。下一步怎么办？

这就进入第二类知识：面对这些信息，应该如何理解、关联、判断和行动。过去，这一层大量依赖业务专家的经验。专家往往会说“这个靠经验”“我感觉这个客户不适合”“这种情况一般不要这么处理”。

这里所谓的“感觉”，很多时候其实是长期实践以后形成的高度压缩判断。问题在于，如果这些判断依据不能被显性化，就难以验证、复制、迁移，也无法稳定地交给Agent使用。

知识类型	含义	电信销售Agent中的例子
传统文档	已经文档化的产品、制度、流程、SOP等	某套餐月费129元、包含100GB流量；套餐变更需要实名认证
规则	什么条件下可以做、不能做或进入下一步	合约未到期不能直接降档；某优惠只能与指定套餐叠加
判断	看到什么信号，可以形成什么判断	客户连续数月流量远低于套餐额度且高度价格敏感，可判断存在过度配置可能
关联	现象、原因、问题和对策之间是什么关系	月费高可能来自增值业务、漫游、设备分期或多号码，并非一定是套餐本身
例外	什么情况下标准规则不适用	VIP客户、历史承诺客户或特殊投诉场景需要人工授权
情景	同一种知识在不同场景下如何变化	初次咨询先识别需求；续约阶段重点比较总成本与权益；投诉中不宜继续普通销售
策略	多个可行方案中为什么优先选择某一个	价格敏感客户优先优化总支出；高频出差客户优先保障覆盖和漫游权益
实践经验	长期实践中形成、未完全写进制度的模式和诀窍	客户说“贵”有时是在试探优惠，优秀销售会先确认真实诉求而不是马上降价

如果这一层没有做好，Agent可能出现另一种问题：看对了信息，却做错了判断。

在实际调研中，即使是有经验的客服人员，他们也通常愿意真诚地帮助客户，也积累了大量一线经验。但由于企业过去很少对“高质量推荐究竟需要获取哪些信息、如何权衡这些信息、最终依据什么形成判断”进行系统分析和研究，客服人员往往只能依赖个人经验和临场判断来处理问题。

这会带来一个直接结果：不同人员面对相似客户，可能提出不同的问题、关注不同的信息、形成不同的判断，最终造成服务质量的不一致。

而且，即使是业务专家个人的经验，也不能天然等同于组织级的专家知识。一个专家的判断可能来自长期实践，但如果没有经过不同专家之间的比较、碰撞、质疑和验证，也很难保证完整性和普遍适用性。

业务专家有经验，不等于企业已经形成了可复用、可验证、可交给Agent的专家级知识。

四、把专家级能力变成Agent能力：KTAF、知识治理与专家培养

到这里，整个问题就非常清楚了。要让Agent真正进入业务，企业至少需要完成两次关键显性化。

第一次，把“专家该看什么”显性化。这是专家级的信息需求知识。

第二次，把“专家看完以后怎么判断”显性化。这包括规则、判断、关联、例外、情景、策略和实践经验。

真正的业务链路应该是：知道该获取什么 → 获得实际信息 → 调用相关知识 → 形成判断 → 采取行动

前者决定输入是否完整，后者决定输出是否可靠。

KMCenter长期形成的KTAF，本来就是围绕“一项复杂工作究竟是如何被高质量完成的”展开。它不是从“企业有哪些文档”开始，而是从真实业务和任务开始。

流程 → 阶段 → 活动 → 任务 → 动作/判断 → 信息需求 → 实际上下文 → 业务知识 → 行动

KTAF首先通过流程、阶段、活动和任务分析，把真正需要Agent参与的工作拆清楚；然后通过动作和判断分析，识别专家在任务中看什么、问什么、查什么、比较什么、判断什么；再通过信息需求分析，把专家级的“该看什么”显性化；随后通过知识分析，把规则、判断、关联、例外、情景、策略和实践经验显性化；最后再明确什么情况下Agent可以自主完成，什么情况下只能辅助，什么情况下必须转人工。

KTAF真正解决的不是“怎么给Agent写Prompt”，而是“怎么把专家完成任务所依赖的两类关键知识建模出来”。

用于Agent的知识建设，也不能简单理解成找一个专家访谈，把他说的话整理下来。个体专家的经验可能不完整、受特定场景影响，也可能存在个人偏好。真正高质量的知识建模，需要多位专家分别分析，再进行比较、讨论、质疑和补充，并结合外部资料与真实业务进行验证和持续修正。

Agent时代的隐性知识显性化，不是简单的经验记录，而是知识重新建模。

两类关键知识被分析出来以后，还需要通过知识治理，才能被Agent长期、稳定、可信地调用。这包括分类体系、元数据规范、本体与语义模型、知识图谱、权限、版本、时效、知识质量和更新责任。

KTAF解决的是“应该分析和显性化什么”，知识治理解决的是“显性化后的内容如何长期、稳定、可信地被使用”。

更重要的是，企业做Agent，不应该理解成“把普通员工AI化”。如果企业只是把几个普通水平员工的经验、话术和处理方式直接自动化，得到的往往只是普通水平的自动化。AI不会因为被自动化就自动变成专家。

真正有价值的做法，是把企业内高水平专家的信息需求、规则、判断、关联、情景、策略和实践经验分析出来，再经过多专家比较、外部验证和真实业务验证，形成相对稳定的专家级知识模型。

企业做Agent，不是在简单把员工AI化，而是在把专家级业务能力AI化。

这也意味着，Agent时代企业仍然需要培养专家，而且专家的重要性反而更高。企业整体专家水平越高，能够形成的高质量知识源就越丰富；知识建模能力越强，就越能把专家能力复制给AI；Agent则进一步把这种能力规模化。

专家水平决定知识源头，知识建模决定能否复制，Agent决定能否规模化。

未来企业真正需要建设的，不只是AI系统，而是一条完整的能力链：专家培养 → 专家级知识建模 → 知识治理 → Agent规模化复制。

过去问答型AI应用的基本逻辑是：文档 → 向量化 → 检索 → 回答。但Agent真正进入业务以后，基本逻辑正在变成：任务 → 专家级信息需求 → 实际上下文 → 专家级判断知识 → 判断 → 行动。

真正决定Agent能否从“会回答问题”走向“高质量完成业务”的，已经不只是模型能力，而是企业能不能真正回答两个问题：为了把这个任务做好，专家到底会看什么？看到了以后，专家到底会怎样理解、判断和行动？

把这两类专家级知识分析出来、验证并建模，才是Agent真正进入企业核心业务的一项关键前置工程。（本文作者为知名知识管理专家作者田志刚,内容摘自《专家级知识体系》一书，您可通过微信号：511956894 与他联系）