07｜数据明明都在，为什么 Agent 还是用不好？

问题可能不在读取能力。文件里记录的是哪种事实、对应哪个对象、在什么时点有效、能够支持什么动作，都需要明确。企业数据可以被打开，并不意味着已经可以共同支撑业务判断。

从数据到可用上下文，中间需要建立身份、语义、来源、时间和权限的关系。这项工作会直接决定 Agent 能否正确理解企业正在发生什么。

物流模拟情境中，某仓库有实物 96 件，其中 24 件已经预留给订单，可售数量为 72 件。这三个数字都正确，却回答不同问题。系统若只看到“库存 96”，就可能把已经承诺给其他订单的货再次分配。

在途数量也不能直接当作现货。货物已经发出、预计到仓、签收、清点完成、质量放行、进入可售状态，代表不同阶段。预测未来供给时可以使用有条件的到货信息，当前履约却只能依据相应的可用条件。

这说明业务字段不只是名称。每个关键数量需要有定义、单位、对象、状态和时间。类似地，“价格”可能是标准价、历史成交价、含税报价或经批准的优惠；“最终稿”可能只是文件名，未必存在客户确认。

建立语义时，应让业务人员和系统使用同一种解释。定义不是由模型从列名自由猜测，而是由数据与业务责任人共同核对，必要时再映射到软件字段。

跨系统资料常使用不同标识。供应商用商品简称，仓库使用内部 SKU，图片标签只写款号与尺码，采购单又采用另一种编码。如果没有可靠对应，后面的计算和解释都会建立在错误连接上。

对象对齐应尽量依赖可核查的标识与映射。无法确认时，可以保留候选并要求人工核对，而不是因为名称相似就自动合并。两条资料是否描述同一批货，还需要结合单据、批次和事件信息，避免重复计数。

礼品设计同样需要对象身份。客户、活动项目、具体作品、版本、参考素材和确认记录各自独立。某客户去年采用的礼盒设计，可以作为当前项目的风格依据，但不意味着今年五件作品都已得到确认。

对象关系一旦清楚，查询就能从“找一张像去年那样的图”，变成“查找该客户指定项目中有确认记录的那件作品版本”。检索依然可以使用模型能力，但检索边界不再依赖模糊印象。

Ontology 常译为本体。在本文的企业交付语境中，可以把它理解为组织业务对象、属性、关系、状态、动作与权限的一种模型。重点是让系统和岗位围绕同一组业务含义工作。

例如设备租赁模型中，有设备类型与具体设备，有操作员与运输车组，有询价、报价版本和资源确认。设备类型的日租标准不能直接说明某台机器可以出场；客户接受某个报价版本，也不能替代调度对具体资源的确认。

可以用一张简图表达这种关系：

这张图说明哪些事实可以连接，不规定必须购买某个平台。小项目可能通过清晰的表结构、映射表和受控接口实现；复杂项目则可能使用专门的建模工具。选择应当服从实际规模与约束。

还应区分几个相近概念。数据库关注数据如何存储；主数据管理关注核心实体的权威身份与属性；知识图谱关注节点与关系；业务语义层帮助统一查询和指标口径。企业 Ontology 的讨论则进一步包含对象能够采取的动作以及治理边界。它们可能协作，但不能随意互换名称。

物流判断至少需要区分业务事件发生时间、系统观察或采集时间，以及预测时间。今天上传的表格可能记录昨天的库存，今天看到的到货通知也可能修改了此前的预测。

“最新文件”不一定包含最新事实。若系统按上传顺序选择来源，可能让旧数据覆盖新状态。应该根据约定的业务时间、来源权威性和版本规则处理，遇到无法消解的冲突则保留差异并交给负责人。

资源可用性也是时间相关的。设备在某两天可以作为候选，不代表第三天仍然空闲；运输可以在上午安排，不代表下午同样成立。客户改期后，原查询结果必须重新评估。

因此，系统输出应尽量携带“基于什么时点、哪个版本、适用于什么条件”的说明。即使不把所有技术字段展示给终端用户，工程记录也需要能够恢复当时判断。

来源管理要求结论能够追到原始资料及其处理过程。例如报价来自哪版价目，库存来自哪个仓库记录，客户确认对应哪封消息，模型提取的尺码来自哪张图片。

不同来源具有不同权限与用途。历史经验可以帮助解释，却未必有权改变当前规则；标签照片可以说明发货方声明的内容，不能单独证明实际收货数量；客户说“方向不错”，可以作为反馈，却未必是正式交付确认。

当来源冲突时，应有具体的处理规则。谁是这类事实的权威责任人？哪些证据优先？是否需要重新核验？无法确认时应暂停哪个动作？模型可以整理冲突，不能在没有授权规则时自行宣布哪份资料有效。

保留来源还方便修复。用户指出结论错误时，团队可以检查原始资料、解析结果、对象映射和后续计算，区分数据错误与模型错误。若只保存最终答案，就很难复现问题。

同一份数据在不同场景下可能允许不同使用。销售可以查公开产品说明，未必可以读取另一客户的咨询；设计师可以查看当前客户授权素材，未必可以把其他客户的专属标识带入新任务。

权限需要在取数、检索、工具执行和输出等环节贯彻。仅在提示词中写“不要泄露”不能代替访问控制。工具返回的数据也需要符合当前身份与任务边界，避免系统先取来全部内容，再期待模型自行过滤。

动作权限应与读取权限分开。能够查看报价，不意味着可以批准优惠；能够查看库存，不意味着可以修改预留；能够生成设计，不意味着可以代表客户确认作品。把这些动作设计为有明确输入、条件和责任的接口，更容易控制与审计。

在开发前，可以为每类关键来源填写下面的记录，并挑一项任务检查是否能够贯通。

完成这张表之后，团队获得的是一组可以使用的条件，而不仅是一堆可读取文件。下一篇会继续把这些条件组织成运行方案，明确模型、规则、工具和人工各自负责哪一段工作。

需要先整理资料、提取关键信息时，可以了解 AI随心创的AI 助手。如果任务涉及团队数据、权限与现有流程，可通过企业 AI 咨询先讨论资料条件与应用边界，再决定后续方案。