之前已经讨论了高质量数据集的质量要求和建设方法。本篇不再重复定义，而是聚焦它在智能体体系中的作用：当 AI 从“回答问题”走向“完成任务”，数据集必须从静态问答样本延伸到任务执行过程；当单智能体走向多智能体协同，数据集还要承担分工约束、状态共享、交接校验和错误归因。

智能体完成一个真实任务，需要理解目标、识别场景、补齐条件、拆解步骤、检索依据、调用工具、解释返回结果、处理异常并接受复核。高质量数据集要为这些环节提供可学习、可执行、可评测的样本，而不是只给出一个看似正确的最终答案。

多智能体进一步把一个任务拆分给规划、制度、业务数据、流程和复核等角色。此时，数据集不仅是模型训练材料，还要成为不同智能体之间的共同语言：明确谁负责什么、交接哪些信息、共享什么状态，以及在什么情况下退回重做或转人工。

在智能体体系中，高质量数据集同时承担三种角色：任务执行的“操作样本”、多智能体协同的“交接契约”，以及系统持续优化的“证据链”。

在普通模型应用中，一个样本通常可以简化为“用户问题—标准答案”。这类数据能够帮助模型学习知识表达和回答方式，但它只描述结果，并不描述任务是如何被完成的。

例如，用户提出：“我准备给一个外部供应商付款，这笔费用是否需要走采购审批？需要提交哪些材料？流程怎么走？”这已经不是单纯的制度问答。智能体不能只引用一段采购制度，也不能在业务条件不完整时直接给出确定性结论。

它需要先识别这是企业制度与流程合规判断任务，再确认付款金额、供应商类型、合同状态、预算状态、采购申请状态和框架协议适用性；随后检索采购、付款、合同和预算制度，调用合同、预算、供应商及审批流系统，最后综合制度依据与业务状态，形成流程建议、材料清单和风险提示。

“问题—答案”样本只能告诉模型最后应该说什么；任务轨迹样本则记录目标如何被理解、条件如何被补齐、步骤如何被拆解、依据和工具如何被调用、中间结果如何被解释、异常如何处理，以及最终结论是否通过复核。后者才真正对应智能体的运行过程。

单智能体要稳定完成任务，数据集必须与任务链逐环节对应。它不是在任务之外提供一批参考材料，而是把任务识别、规划、检索、调用、判断、异常处理和反馈修正沉淀为可复用的执行样本。

任务意图与场景数据首先解决“用户到底要做什么”。同一句“帮我看看这笔付款怎么走”，可能对应制度查询、采购合规判断、审批路径推荐或材料清单生成。高质量样本需要同时记录用户表达、业务场景、已知条件和仍需追问的信息，避免智能体在起点就选错任务。

任务规划与依据数据解决“应该按什么顺序完成”。对于供应商付款任务，合理路径通常是确认背景、检索制度、核对合同与预算、查询授权矩阵、判断审批分支，再生成材料清单和风险提示。规划样本不仅给出步骤，还应标明每一步的前置条件、决策依据和停止条件。

工具调用数据解决“何时调用什么工具、如何填写参数、怎样解释返回结果”。制度检索、合同系统、预算系统、供应商系统和审批流查询工具都可能参与同一任务。调用样本应记录工具名称、触发条件、输入参数、返回值、时间戳和结果解释，使调用过程能够复现和评测。

状态判断与异常处理数据解决“信息不完整或相互冲突时怎么办”。预算编号缺失、合同状态不明、制度版本冲突或接口返回失败，都不应被模型自动补全。样本需要明确何时追问、何时重试、何时给出保守结论，以及何时转交人工。

复核与反馈数据解决“如何判断任务是否真正完成”。它既要检查最终结论，也要检查依据是否有效、过程是否完整、风险是否充分表达。专家修正和用户反馈还应回流为新的正确轨迹、异常样本和边界样本。

高质量数据集并不替代智能体推理，而是约束任务链中的关键动作：让每一步都有依据、每一次调用能够复现、每一种异常都有处理策略、每一个结论都可以追溯。

一条真正可用于训练、评测和复盘的任务轨迹，至少要形成“输入快照—执行过程—输出结果—反馈回流”的闭环。仍以供应商付款审批判断为例，样本既要记录用户提出了什么，也要记录系统掌握了哪些条件、调用了哪些依据与工具、形成了什么中间状态，以及为什么得出最终结论。

表1 企业制度与流程任务轨迹样本字段

这类样本与传统问答数据的根本差异，在于它保存了任务执行时的“状态”。同一个问题在不同金额、不同合同状态、不同预算状态和不同制度版本下，可能对应完全不同的流程。只有记录输入快照、依据版本、工具结果和中间判断，系统才知道结论适用于什么条件。

完整轨迹还使一次任务同时服务于多种用途：成功轨迹可以用于训练和示范，失败轨迹可以用于诊断，边界案例可以用于稳健性评测，专家修正可以形成下一轮优化样本。数据集由此不再只是答案集合，而成为任务能力的可复用载体。

随着任务复杂度提高，单个智能体很难同时承担规划、制度检索、业务查询、流程判断和质量复核。企业流程场景通常会逐步形成 Planner、Policy、Business Data、Workflow和 Review 等角色，由多个智能体共同完成一个任务。

角色分工本身并不会自动带来协同。Planner 需要把任务目标和必要条件交给下游；Policy 需要传递制度条款、版本和适用范围；Business Data 需要返回合同、预算和供应商状态；Workflow 需要基于共享状态选择流程分支；Review 则要检查依据、过程和风险是否完整。

因此，每一次智能体交接都应形成结构化的“交接包”，至少包含当前任务目标、已确认的业务事实、使用的制度版本、已完成的工具调用、中间结论、未解决问题和下一步动作。交接数据不是聊天记录的简单转发，而是多智能体之间可校验的数据契约。

共享状态同样关键。付款金额、合同编号、预算状态、制度版本和流程节点必须在多个智能体之间保持一致；一旦标识、版本或状态在传递中丢失，即使每个智能体局部判断都合理，最终结果仍可能失败。

图5所示的能力分层说明了这种协同为什么需要完整的数据底座：基础设施保证稳定运行，元数据与治理层保证数据可信可控，数据资源层提供标准化业务事实，结构化表达层组织实体、规则和流程，应用能力层则沉淀任务样本、轨迹、评测和反馈。多智能体协同依赖的不是某一类数据，而是这些层次共同形成的体系能力。

高质量数据集只有进入智能体运行平台，才能真正转化为任务能力。平台需要把知识库、业务数据、模型服务、工具服务、流程引擎和协同编排组织在一起，并为每次执行保留可追溯的日志和状态。

图6展示了一个企业制度与流程智能体平台的典型分层。应用层承载任务入口和业务场景；智能体层负责任务分工、协同编排和状态管理；知识与数据层同时提供制度知识库和高质量任务数据集；平台服务层提供模型、检索、流程、评估和集成能力；基础设施与运维层保障安全、性能、监控和持续迭代。

平台化并不意味着评测只看最终输出。多智能体系统仍然要对任务规划、制度检索、业务查询、工具调用、状态共享、流程判断、结果复核和最终输出分别评测，并把错误定位到具体角色、具体步骤和具体数据。

表2 多智能体协同评测与错误归因项

分环节评测的价值，在于把“系统答错了”转化为可执行的改进任务。规划错误应补充任务拆解样本，制度版本错误应修复知识和版本管理，参数错误应补充工具调用样本，状态丢失应修正交接契约，复核遗漏则需要强化检查规则。只有错误能够被定位和归因，系统优化才不会停留在泛泛增加数据。

智能体数据集不应完全依赖人工预先编写。更可行的方式，是从高价值业务场景出发，先定义标准任务路径和关键状态，再通过真实运行持续采集日志、工具调用、异常、人工接管和复核结果。

原始日志并不能直接成为高质量数据。还需要对任务边界、输入快照、调用参数、中间状态、输出结果和错误类型进行结构化加工，再由业务专家校验关键依据和判断逻辑，形成可用于训练、评测和回归测试的标准样本。

运行反馈可以沉淀为四类重要资产：能够稳定完成任务的正确轨迹，接口失败或条件缺失形成的异常样本，框架协议、金额阈值等形成的边界样本，以及专家修正形成的纠错样本。它们共同决定系统能否从一次运行中学习。

为了让这些数据长期可用，还需要持续管理版本、血缘、权限、脱敏、质量状态和适用范围。制度更新、接口调整或流程变更后，相关任务样本和评测集也必须同步更新，否则历史上的正确轨迹可能成为新的错误来源。

智能体数据建设是否成熟，不取决于累计了多少条样本，而取决于每一次失败能否被定位、解释、修正，并转化为下一轮系统优化的有效数据。

高质量数据集对智能体的价值，已经超出模型训练。对于单智能体，它把任务理解、规划、工具调用、状态判断、异常处理和复核反馈组织成可执行的任务轨迹；对于多智能体，它进一步把角色职责、共享状态、任务交接和错误归因固化为协同规则。

没有任务轨迹，智能体只能学习怎样回答；没有结构化交接和共享状态，多智能体只能形式上分工；没有分环节评测和错误归因，系统就无法知道失败发生在哪里，也无法把一次修正沉淀为长期能力。

因此，高质量数据集不是智能体体系的附属材料，而是连接知识、数据、模型、工具、流程和反馈的系统资产。它真正支撑的，是智能体在真实业务中稳定完成任务、可靠协同，并在持续运行中不断改进。