作者：卢向东，杭州萌嘉网络科技有限公司创始人。团队长期专注于企业 AI 落地与 AI 知识引擎实践，是国内较早探索 RAG 企业应用落地的团队之一。产品 TorchV 已成功服务浪潮信息、微众银行、物产中大、台州银行、适途汽车、中汇税务师事务所等客户。
导读：
- 企业Agent的四个要素；
- 企业上下文的五个分类；
- 如何构建为Agent服务的企业上下文。
就今年的市场需求来看，从很多人在问Agent可以做什么，到现在的Agent已经开始逐渐在一些我们可以接触到的企业的核心业务中出现，Agent真的越来越火了。从最早的聊天问答，到现在能够搜索资料、操作文件、调用系统、生成报告，甚至自主拆解和执行复杂任务，Agent正在从一种技术概念，逐渐进入企业的真实业务场景。
但在实际项目中，我越来越强烈地感受到一件事：企业Agent好不好用，关键可能不是模型，而是上下文。
当然，这并不是说大模型不重要，Agent最主要的发动机就是大模型，可以说是大模型决定了Agent的上限。但对大多数企业和AI应用公司来说，能够获得的大模型能力其实正在逐渐趋同，不管你是私有化还是调用在线模型。
所以，大模型很重要，却未必能够成为企业Agent长期的差异化优势。
一、决定企业Agent效果的四个因素
经过这段时间的思考，以及我们在多个企业知识库+Agent项目中的实践，我现在更愿意用下面四个因素来理解企业Agent：
企业Agent有效性＝大模型能力×企业上下文×工具能力×治理评测
这里使用乘法，而不是加法，是因为任何一项明显不足，都会影响Agent的整体效果。
第一，大模型能力
大模型决定了Agent能不能理解复杂要求、拆解任务、进行推理和处理不确定性。模型越强，Agent可以承担的任务就越开放、越复杂。
但是，对于大部分企业来说，模型更多是一种可以采购和接入的通用能力。除非企业本身就在训练基础模型，否则大家能获得的模型能力通常不会有本质差距。再往后说，类似DeepSeekV4发布，你针对DeepSeek-V3/R1微调的模型依然是不够看的。
第二，工具能力
Agent不能只是“知道应该怎么做”，还要能够真正完成操作。
例如，一个采购Agent即使知道公司的采购制度和供应商情况，如果不能查询ERP、读取合同、发起审批或者发送通知，它仍然只能给出建议，不能真正把事情做完。所以，工具决定了Agent能不能从“会想”走向“会做”。
第三，企业上下文
企业上下文决定了Agent是否真正理解这家企业。
一家企业的制度、流程、产品、客户、历史案例、会议纪要、项目经验、岗位职责和内部习惯，不可能天然存在于大模型中。如果缺少这些信息，Agent给出的结果可能很专业、很完整，甚至看起来很有道理，但就是不符合这家企业的实际情况。
第四，治理与评测
Agent能够执行任务，并不等于它可以进入生产环境。
我们还想知道的是：它使用了哪些依据？有没有遗漏重要规则？是否越权访问数据？执行过程能不能回溯？失败之后如何恢复？哪些操作必须经过人工审核？
特别是在金融、保险、制造、审计和专业服务等场景中，一个“多数情况下表现不错”的Agent，远远不够。它必须是可评测、可控制、可追溯和可持续优化的。
图：企业Agent有效性公式，由模型智能、企业上下文、工具能力和治理评测四个因素相乘构成
二、为什么企业上下文可能是最重要的差异
在这四个因素中，我最想讨论的还是企业上下文。
因为模型可以买，工具可以接，评测体系也可以逐步建立，但企业长期积累的知识、规则、经验和工作方式，往往很难被竞争对手直接复制。
大模型知道公开世界中的大量知识，但它不知道企业内部的很多事情。
比如：
- 这家公司目前执行的是哪一版制度；
- 总公司的规定和分公司的细则有什么不同；
- 某类客户通常采用什么处理方式；
- 哪些问题虽然制度没有明确禁止，但内部非常谨慎；
- 某个项目为什么上一次失败了；
- 某类设备出现故障时，老师傅通常先检查什么；
- 某位用户属于哪个部门，可以看到哪些内容；
- 当前任务已经执行到哪一步，还缺少什么材料。
这些信息，才是Agent在企业里真正做对事情的基础。
所以我经常用一句话来概括：
模型让Agent聪明，工具让Agent做事，企业上下文让Agent做对这家企业的事。
缺少企业上下文的Agent，就像一个能力很强、学习很快，但做的事情好像是自己的私活，和公司没什么关系。
三、企业上下文不只是“上传一些文件”
很多人谈企业上下文时，会立刻想到知识库。把制度、手册和案例上传进去，再通过RAG检索几段内容交给大模型，似乎就完成了上下文建设。但实际情况远比这复杂。
企业上下文至少可以分成五类。
1. 规则上下文
这件事应该怎样做，哪些事情不能做。
它包括法律法规、监管要求、企业制度、业务流程、操作规范、合规红线、审批规则和输出模板等。
例如银行对客服务Agent，不仅需要知道产品信息，还需要知道不能承诺收益、不能诱导客户过度消费，在某些回答中还必须附带风险提示和免责声明。
规则上下文决定了Agent的行为边界。
2. 事实上下文
当前真实情况是什么。
例如客户信息、产品参数、订单状态、库存数量、合同内容、设备状态和项目进度。
这类上下文往往不是只靠文档知识库就能解决的，还需要查询数据库、业务系统或者实时接口。
如果Agent拿到的是过期事实，即使推理过程完全正确，最终结果也可能是错的。
3. 经验上下文
过去遇到类似问题时，我们是怎么处理的。
它包括历史案例、项目复盘、审批意见、售后工单、专家经验、成功样本和失败教训。
企业里最有价值的知识，很多时候不是写在正式制度中的，而是隐藏在一次次项目和业务处理中。
规则告诉Agent“原则上应该怎么做”，经验则告诉它“在类似情况下，我们以前是怎么做的”。
4. 任务上下文
这一次具体要做什么，现在做到哪一步。
它包括用户目标、当前文件、前序步骤、中间结果、临时约束、待办事项和Agent已经采取的行动。
任务上下文通常是动态的。当Agent执行一项持续几小时、几天甚至更长时间的任务时，它不能每次都从头开始，也不能忘记前面已经得出的结论。
5. 组织与用户上下文
谁正在做这件事，他能够看到什么，又可以做到什么程度。
它包括用户所属部门、岗位职责、数据权限、审批关系、常用模板和表达习惯。
同一个问题，由普通员工、部门负责人和公司管理层提出，Agent能够看到的内容、回答的颗粒度和可以执行的操作都可能不同。
图：企业上下文五类模型，包括规则上下文、事实上下文、经验上下文、任务上下文以及组织与用户上下文
四、知识库到底应该怎样分类
在实施企业知识库时，客户经常会问我们一个问题：
知识库到底应该怎样划分？
目前比较常见的做法主要有三种：
按组织架构划分，例如总公司、分公司、部门和业务小组。
按业务场景划分，例如汽车售后可以分为事故救援、日常保养、配件管理、召回和服务预约。
按产品线划分，例如服务器厂商可以按照不同产品系列、设备型号和故障集建立知识库。
这些方法都没有错，而且非常符合企业管理习惯。
因为知识库分类首先要解决的，不是Agent如何使用，而是：
这是谁的知识？谁负责维护？谁有权查看？内容发生变化后谁来更新？
但是企业会不断发展，特别是借助AI的发展，有很多创新尝试，需要面向这些创新主题来维护上下文。
所以，我们目前更倾向于采用一种双层设计。
第一层是知识库。
知识库按照组织架构、业务领域、产品线和安全边界建设，负责知识的长期管理。
它重点解决：
- 知识归谁负责；
- 谁可以维护和发布；
- 哪些用户可以访问；
- 当前版本是否有效；
- 知识是否重复、冲突或者过期。
第二层是知识空间。
知识空间不是另一个重复存放文件的知识库，而是围绕一个项目、主题或者Agent任务，对多个知识来源进行灵活组合。
例如，一个“采购合同审核空间”，可能需要同时使用：
- 法务部门维护的合同制度；
- 采购部门维护的采购办法；
- 财务部门维护的付款规则；
- 历史合同争议案例；
- 当前供应商资料；
- 本次待审核合同；
- 当前项目会议纪要；
- 审核报告模板。
这些内容专门维护在采购合同审核的知识空间中，知识空间可以根据权限，复制不同知识库中的内容，同时容纳当前项目文件、任务记录和Agent执行过程中产生的中间结果。当知识库中的原始文档发生了更新，知识空间的维护者也可以获得通知，决定是否进行更新。
这就形成了一个比较清晰的分工：
知识库面向知识生产和治理，知识空间面向知识消费和业务协作。
而规则、事实、经验、任务、组织与用户这五类上下文，则更适合作为一种语义分类维度。
一份知识可以同时拥有多个上下文属性。Agent在执行任务时，可以根据当前步骤选择不同类型的内容。
图：企业上下文三层架构，底层为按组织业务和产品建设的知识库，中间为面向项目与场景的知识空间，上层为Agent运行时动态上下文装配
五、真正优质的上下文，需要在运行时动态装配
即使知识空间已经聚合了大量相关内容，也不能一次性把所有资料都塞给大模型。上下文不是越多越好，无关内容太多，会干扰模型判断；新旧制度同时出现，可能造成冲突；敏感信息被不必要地传入模型，也会增加安全风险。
Agent真正需要的是：
完成当前任务所需的最小充分上下文。
以合同审核为例。在识别合同类型时，Agent可能只需要当前合同、项目基本信息和合同分类规则。在检查关键条款时，它需要标准模板、法律法规、内部制度和风险规则。在评估商业风险时，它还需要供应商信息、历史合作记录和类似争议案例。最后生成审核意见时，它需要前面各步骤的中间结论、风险等级、输出模板和当前用户的身份信息。
所以，企业上下文不是一个静态资料包，而应该是根据用户、任务、步骤、权限和风险动态生成的上下文快照。
这也是我们现在思考TorchV AIS下一步演进时，非常关注的一个方向。
过去我们更多强调企业知识库、知识加工、知识健康、混合检索、引用溯源和Agent调用这个知识工程的过程。接下来，这些能力可以进一步被一条“企业上下文”的主线连接起来：
- 通过知识库长期承载企业知识；
- 通过知识加工将原始资料转化为高质量知识对象；
- 通过知识健康处理重复、冲突、过期和低质量内容；
- 通过知识空间按场景组合不同来源的知识；
- 通过Agentic RAG和原子命令按任务调用知识与工具；
- 通过权限、评测、日志和人工审核控制Agent执行；
- 通过业务反馈持续优化企业上下文。
这时候，TorchV AIS就不再只是一个提供RAG检索的知识库，而是一套面向企业Agent的上下文基础设施。
图：TorchV AIS企业上下文闭环，从知识接入、加工、准入、治理，到空间组合、动态调用、Agent执行、评测反馈与持续优化
七、企业Agent的竞争，最终是组织能力的竞争
回到最开始的问题。
企业Agent好不好用，模型当然重要，但只比较模型是不够的。
随着大模型能力逐渐普及，企业之间真正的差距，可能越来越来自下面这些问题：
- 企业是否把自己的规则讲清楚了？
- 业务流程是否能够被Agent理解和执行？
- 历史案例和专家经验有没有沉淀下来？
- 实时业务数据能不能被安全调用？
- 知识是否有明确的版本、权限和责任人？
- Agent执行之后，结果能不能评测，错误能不能反馈，知识能不能持续优化？
所以，企业上下文建设表面上是技术问题，背后其实是企业知识管理、流程管理和组织治理能力的集中体现。
一家企业拥有再多文件，如果没有加工、分类、权限、版本和使用机制，这些文件也很难成为Agent真正可以调用的上下文。
而当制度、事实、经验、任务和组织信息能够被持续治理，并在正确的时间提供给正确的Agent时，企业AI才真正开始从通用能力变成自己的生产力。
大模型提供的是通用智能，企业上下文提供的，才是这家企业自己的知识、规则、经验和做事方式。
未来企业Agent真正比拼的，可能不是谁接入了更强的模型，而是谁能够更好地构建、治理和使用自己的企业上下文。