5 把 Agent 任务翻译为数据需求

本章产出： 一份可以由产品、架构、数据治理、安全和业务共同评审的 Agent 数据需求说明书。

企业第一次讨论 Agent 时，会议上最常出现的需求是：“把公司的知识接进来，让它能够回答问题。”这句话听起来明确，实际上几乎无法执行。什么叫公司的知识？回答谁的问题？答案错了会造成什么损失？信息应该新到什么程度？用户是否有权看到答案背后的原始记录？Agent 给出建议之后，是停留在对话框里，还是可以修改工单、发送报价、预订库存？这些问题不被拆开，“接入知识库”就只是一句技术愿望。

数据产品经理的第一项工作，不是立即罗列数据库表，而是把一个含混的智能化设想翻译成可验证的任务，再把任务翻译为事实、规则、上下文、权限和反馈。这个翻译过程决定了后面的数据架构究竟是服务于业务闭环，还是只搭建了一套看上去先进的基础设施。

5.1 从聊天愿望回到工作任务

Agent 与传统报表的不同，不只是交互方式变成了自然语言。报表通常把已经计算好的指标呈现给人，由人理解并行动；Agent 则可能理解意图、选择工具、检索证据、组织答案，甚至代表用户执行动作。数据需求因此不能只描述“它要知道什么”，还必须描述“它在什么条件下可以做什么”。

可以用“任务—判断—行动”三层结构拆解场景：

任务层说明用户要完成的工作。例如，售后工程师需要在到达客户现场后的十分钟内判断设备故障原因。
判断层说明完成任务必须做出的关键判断。例如，故障是否由已知批次缺陷引起，当前固件是否适用某份维修手册，替换零件是否在保修范围内。
行动层说明判断之后允许发生的业务动作。例如，生成排查步骤、推荐备件、创建工单；而库存锁定、费用减免和对外承诺仍需人工审批。

只有把行动写出来，风险边界才会显现。一个仅供内部查询的问答错误，可能只是浪费几分钟；一个自动向客户发送错误维修承诺的 Agent，则可能产生合同和品牌风险。两者不能采用相同的质量门槛、权限模型和上线流程。

以本书的虚构案例“山城精工”为例，首期“售后诊断与备件协同助手”不是笼统地回答设备问题，而是完成如下任务：识别设备及其配置，结合故障码和现场描述提出有证据的排查步骤，匹配适用手册和历史相似工单，推荐可用备件，并将诊断摘要写入草稿工单。首期明确不允许 Agent 自动锁定库存、不允许修改保修状态，也不允许在证据不足时对客户作出结论性承诺。这几条“不做什么”，与功能清单同样重要。

5.2 Agent 需要的五类上下文

当任务边界明确后，不要立即按系统来源列需求。Agent 并不关心某条记录来自 ERP 还是 MES，它关心的是当前任务缺少哪一类上下文。更适合的分类是事实、规则、经验、状态和身份。

上下文类型	要回答的问题	山城精工示例
事实	对象客观上是什么	设备序列号、型号、部件清单、客户、合同
规则	当前应该怎样判断	保修政策、维修规范、审批阈值、安全禁令
经验	过去如何解决过	历史工单、故障案例、专家处置记录
状态	此刻发生了什么	实时告警、固件版本、库存量、工单进度
身份	谁在什么情境下提问	用户、岗位、所属区域、客户授权、会话目的

五类上下文的治理方式并不相同。事实需要主数据标识和关联完整性；规则必须管理版本、生效时间和适用范围；经验需要去除低质量结论并保留处置结果；状态需要明确刷新频率和事件时间；身份则决定最小权限和信息遮蔽。如果把它们全部切成文本块放入向量库，检索系统可能找得到相似句子，却无法判断规则是否过期、库存是否仍然有效，也无法知道当前用户是否有权查看客户价格。

这里还要区分四个时间：业务事件发生的时间、数据进入源系统的时间、进入 Agent 服务的时间、Agent 实际使用的时间。所谓“实时”只有在说明这四者之后才有意义。设备告警或许需要分钟级可见，维修手册可接受每日同步，历史结案工单可以按小时更新，保修规则则必须在生效前完成发布。不同数据项应拥有不同的新鲜度目标，而不是全链路追求昂贵且没有必要的实时化。

5.3 从任务步骤生成数据清单

一份可执行的数据需求说明书，至少要把每个任务步骤映射到数据对象、关键字段、语义、时效、来源、责任人和失败处理。可以按以下顺序展开：

5.3.1 第一步：写出最小任务流程

把一次成功任务写成可观察的步骤，而不是写成系统功能。山城精工的流程可以是：识别设备—核对配置—理解故障—召回证据—检查规则—生成建议—确认备件—记录反馈。每一步都应有输入、输出和停止条件。

5.3.2 第二步：声明必须知道与最好知道

“必须知道”的信息缺失时，Agent 应拒绝继续或转人工；“最好知道”的信息缺失时，可以降低置信度并提示。设备序列号、适用手册版本和安全警告属于前者；同地区相似案例可能属于后者。这个区分可以阻止团队为了追求数据完美而无限扩大首期范围。

5.3.3 第三步：定义实体与连接关系

Agent 的价值往往产生在跨系统关联处。序列号要连接设备型号和出厂配置，型号连接手册适用范围，零部件连接库存与替代关系，客户连接合同和保修政策，故障码连接历史处置。需求必须明确连接键、匹配规则和冲突优先级。例如，设备实际配置与标准物料清单冲突时，是信任最近一次现场变更记录，还是信任 ERP？这不是数据库连接语句能够替业务决定的问题。

5.3.4 第四步：给语义下定义

字段名称相同不等于含义相同。“可用库存”可能指账面数量，也可能是扣除锁定、质检和在途影响后的可承诺数量。“结案”可能指工程师完成工作，也可能指客户验收和财务结算全部完成。需求说明书要给出业务定义、计算口径、枚举值、单位、时区和空值含义，并指定语义负责人。

5.3.5 第五步：量化服务等级

数据质量不能只写“准确、及时、完整”。应为关键数据项定义可验证指标：设备标识匹配成功率、手册适用范围覆盖率、故障案例有效率、库存最大允许延迟、权限判定响应时间、检索结果中带来源的比例，以及服务不可用时的降级方案。服务等级要从任务风险倒推，而不是从平台现有能力顺推。

5.4 输出也是一份数据契约

许多团队认真设计输入，却把 Agent 输出当作一段自由文本。企业场景中的输出最好具有结构化契约。例如诊断结果可以包含：

asset_id: 设备唯一标识
summary: 诊断摘要
possible_causes:
  - cause: 可能原因
    confidence: 0-1
    evidence_ids: [证据标识]
recommended_steps:
  - sequence: 1
    action: 排查动作
    safety_notice: 安全提示
parts:
  - part_id: 备件编码
    recommendation_only: true
limitations: 信息缺口与适用限制
decision: answer | clarify | abstain | escalate

结构化输出并不妨碍 Agent 用自然语言表达，它让下游系统、评估程序和审计人员能够理解一次回答由什么组成。尤其是 evidence_ids、limitations 和 decision，它们把“有根据地回答”和“知道何时不回答”变成了产品能力。

需要强调的是，企业无法绝对消灭大模型幻觉，但可以缩小它能够自由发挥的空间。可靠性的来源不是一句“请不要编造”的提示词，而是经过治理的上下文、受约束的工具、明确的输出模式、可追溯证据、风险门禁和拒答机制。对于高风险字段，可以要求答案只能从工具返回值填充；对于关键操作，可以执行确定性校验；当证据冲突或覆盖不足时，应主动澄清、拒答或升级给人。

5.5 权限要约束数据，也要约束动作

传统数据权限常停留在库、表、行和列。Agent 还引入了会话权限、目的限制、工具权限和动作权限。同一个售后工程师可以查看自己负责客户的设备信息，却未必能够看到完整价格折扣；可以查询库存，却不能锁库；可以生成工单草稿，却不能代替客户签字。即便用户分别有权访问两类信息，也不代表系统可以把它们组合后向第三方披露。

因此每项需求都要回答五个问题：谁可以请求，出于什么业务目的，可以读取哪些范围，可以调用什么工具，产生什么动作需要谁批准。敏感字段应在检索前过滤，而不是在模型已经看见后再要求它“不要说”。工具调用应使用短期身份和最小权限，所有关键读取、规则版本、证据引用和动作结果都进入审计记录。

5.6 反馈不是点赞按钮

反馈闭环必须能够定位失败发生在哪一层。一个“答案没帮助”的评价可能源于设备识别错误、源数据过期、关联失败、检索遗漏、规则冲突、模型理解错误，也可能只是用户没有采用正确流程。若只保存赞与踩，团队很难决定下一步该修数据、检索、提示词还是业务规则。

更有效的反馈记录至少包括：任务和会话标识、输入条件、使用的数据与规则版本、召回证据、Agent 输出、人工修改、最终动作、业务结果和失败分类。山城精工可以把工程师对“故障原因、排查步骤、推荐备件”的修改分别记录，并在工单结案时回填真实原因和实际使用备件。这样历史工单不再只是静态文档，而会逐步成为有结果标签的经验数据。

反馈进入生产数据前还需要审核。用户修订不一定正确，模型生成内容更不能未经验证便反哺知识库，否则系统会把自己的错误循环放大。高价值反馈应经过责任人确认、去重、脱敏和版本化，再成为新的规则、案例或评测样本。

5.7 用验收场景代替抽象承诺

Agent 数据需求最终要通过场景验收。测试集既要包含常见成功案例，也要覆盖关键边界：

序列号存在但配置记录缺失时，是否要求补充信息；
两份维修手册发生版本冲突时，是否选择对当前型号和日期有效的一份；
库存服务超过允许延迟时，是否只展示“待确认”而非具体承诺；
用户无权查看价格时，输出和证据中是否都完成遮蔽；
历史案例相似但适用型号不同，是否避免错误迁移；
问题超出证据覆盖范围时，是否拒答并转给专家；
工具调用失败时，是否保持幂等，避免重复创建工单。

每个验收场景都要明确预期答案、允许误差、禁止行为和所需证据。离线评测验证任务正确性，影子运行观察真实流量，有限人群试点验证流程价值，上线监控则持续检查漂移与异常。只有四者结合，需求才从文档变成可运营的承诺。

5.8 本章交付物：Agent 数据需求卡

建议为每个候选任务建立一张数据需求卡，至少包括以下内容：

模块	应填写的内容
用户与任务	谁在何种情境下完成什么工作
判断与行动	关键判断、允许动作、审批动作、禁止动作
上下文	事实、规则、经验、状态、身份
数据对象	实体、关键字段、关联键、来源与负责人
语义契约	口径、单位、版本、生效范围、冲突规则
服务等级	新鲜度、完整性、准确性、覆盖率、响应时间
安全要求	读取范围、字段遮蔽、目的限制、工具权限
输出契约	结构、证据、限制、拒答与升级状态
反馈设计	人工修订、最终结果、失败分类、回流审核
验收方案	黄金样本、边界样本、指标、上线门槛

这张卡是产品需求与数据架构之间的接口。产品经理用它说明任务价值和体验边界，架构师据此选择批流链路、语义层、检索方式和服务接口，治理与安全团队据此定义责任和控制，业务专家则确认规则是否真实。做到这一步，“让 Agent 使用企业数据”才不再是一句口号，而成为一组可以建设、测试、审计和持续改进的数据承诺。