第 5 章 数据、知识与上下文：稳定产出与 Agent 协作的运行底座
前面章节解决了能力边界、任务定义和工作流设计问题。但再好的 Prompt、Skill 或 Agent，如果每一步拿到的数据、知识和运行上下文本身过期、冲突、越权或无关，输出仍然难以稳定。
对企业而言，数据是原材料，知识是经确认的规则与事实，上下文则是特定任务、状态与权限下允许进入模型推理的最小必要信息集合。 三者相互关联，但不能混为一谈。把全部文档、聊天历史或工具结果一次性塞给模型，并不等于给了它更好的上下文；这通常只会增加噪音、成本、泄露风险和错误决策的机会。
本章讨论如何把分散的资料、规则、任务事实、运行状态、工具返回和必要记忆，组织为可验证、可追溯、可维护、可回退的运行底座。其适用于固定工作流，也适用于受限 Agent。对于 Agent，推荐使用以下入门理解：
受控 Agent = LLM + 最小必要上下文 + 受控工具 + 任务/状态契约 + 身份权限 + 验证批准 + 可观测性 + 人工接管与回退。
其中，上下文不是提示词的同义词。公开工程实践将其定义为模型每次推理时可用信息的持续策划与维护，范围可包括系统指令、工具定义、外部数据、消息历史和状态；其目标是以尽可能小、但足够高信号的信息集合支撑期望行为。1
一、从数据质量到上下文质量
1. 为什么“资料正确”仍可能产生错误输出
同一条业务规则即使内容正确，若在错误任务、错误客户范围、错误时间、错误权限或大量无关资料中被调用，仍可能导致错误结果。下表说明数据、知识与上下文分别解决什么问题。
| 对象 | 它回答的问题 | 典型例子 | 常见失效方式 |
|---|---|---|---|
| 数据 | 原始记录是什么？ | 会议转写、交易记录、表单字段、系统日志 | 缺失、错位、格式异常、未经批准使用 |
| 权威知识 | 哪些规则或事实可以作为依据？ | 当前产品政策、审批规则、标准 SOP、已发布合同条款 | 过期、冲突、无 Owner、没有生效范围 |
| 任务上下文 | 此刻要解决什么，面向谁，在什么边界内？ | 客户问题类别、会议类型、任务目标、允许输出 | 目标模糊、对象错配、范围膨胀 |
| 运行状态 | 当前任务已完成什么、还缺什么、处于哪个合法步骤？ | 已审批/待审批、检索完成、工具超时、待人工确认 | 状态丢失、重复执行、越过审批节点 |
| 工具结果 | 外部系统在本次调用中返回了什么？ | 查询结果、代码测试报告、工单详情、库存状态 | 返回过长、无关、错误、恶意或未经核验 |
| 持久记忆 | 哪些跨轮次信息可以保留并在后续引用？ | 已确认的决定、未解决问题、工作笔记、项目偏好 | 把假设写成事实、过期、跨用户混用、无法删除 |
核心原则： 只有具备明确任务、来源、范围、时效和权限边界的信息，才可以成为正式运行上下文。模型不能仅凭生成机制保证企业私有事实、权限或时效正确；即使接入检索或工具，也仍需通过来源、版本、范围和验证控制来证明结果可用。1 3
2. 上下文质量八项标准
原始数据的完整性、准确性、时效性、一致性和可读性仍然必要。进入正式 Skill、工作流或 Agent 前，还应增加相关性、可定位性、最小必要性和权限适配等检查。
| 标准 | 要求 | 最低验证方式 | 典型失败信号 |
|---|---|---|---|
| 相关性 | 信息与当前任务、对象和决策问题直接相关 | 说明每类上下文为何进入本次任务 | 大量背景资料被加载，但无法支持当前决定 |
| 权威性 | 规则和事实来自被批准的来源 | 标注来源、Owner、版本和生效范围 | 搜索结果、旧文档或个人笔记被当作正式政策 |
| 完整性 | 支持任务的关键字段、条件和例外没有缺失 | 对照任务字段与边界清单 | 有结论但无适用条件、日期或例外处理 |
| 时效性 | 信息在本次使用时仍有效 | 记录更新时间或生效日期；触发复核 | 已下架产品、失效价格、过期流程仍被引用 |
| 一致性 | 同一事实或规则无未解释冲突 | 冲突时显示来源并转人工或按优先级处理 | 多份文档互相矛盾，模型任选其一 |
| 可定位性 | 人工可以追溯到具体来源、片段或工具记录 | 输出保留来源ID、链接、版本或证据位置 | 只能看到“AI 说了什么”，看不到依据 |
| 最小必要性 | 仅提供完成当前任务所需内容 | 设置字段、文件、返回量或 token 预算 | 全量知识库、完整会话历史、整库日志被注入 |
| 权限适配 | 上下文的读取、保存和外发均符合数据与角色边界 | 检查数据分级、访问权限、留存和目的 | 使用者或 Agent 看到不应访问的客户、人员或商业信息 |
这些标准不要求每个低风险试点都建立复杂平台。对简单、内部、只生成草稿的 Skill，可以用一页上下文包和人工检查完成；对跨系统、对外沟通、长期运行或有工具动作的 Agent，则应把这些要求固化为可审计的运行控制。
二、企业上下文的六类资产
1. 权威知识、示例与反馈仍是基础
企业知识库仍应以三层结构维护：基础层存放已批准的产品、规则和流程；示例层存放正常、边界和历史失败情形；反馈层记录运行中发现的错误、缺失和修复线索。三层共同服务于 Skill、工作流与 Agent，但它们不是 Agent 可随意访问的“全量资料池”。
| 知识层 | 内容 | Owner | 进入上下文的方式 |
|---|---|---|---|
| 基础层 | 产品文档、业务规则、流程规范、术语、政策 | 知识 Owner | 按任务和权限检索权威片段，显示版本与生效范围 |
| 示例层 | 正常输出、边界案例、历史失败与修复案例 | Skill/流程 Owner 与使用者 | 选择少量有代表性的示例，用于说明预期行为与禁止行为 |
| 反馈层 | 错误、遗漏、审核修改、用户问题和事件线索 | 使用者与运行 Owner | 先作为待验证线索；确认后才进入示例层或基础层 |
知识责任人不必是技术岗位，但必须有权确认规则来源、适用范围和生效日期。未明确 Owner、无来源或已过期的内容，不应作为高影响任务的权威依据。
2. 任务、状态、工具结果和记忆是运行资产
当系统从单次生成发展为多步工作流或 Agent 时，除知识库外还会出现四类运行资产：任务上下文、合法状态、工具结果和持久记忆。它们必须有不同的生命周期。
| 资产 | 默认生命周期 | 可以写入什么 | 不应承担什么 |
|---|---|---|---|
| 任务上下文 | 当前任务结束即失效，除非组织政策另有规定 | 任务目标、对象范围、用户提供的经批准材料 | 不能替代长期知识库或个人档案 |
| 运行状态 | 当前工作流或 Agent 运行期间 | 已完成步骤、待审批事项、异常、重试计数 | 不能绕过状态机、审批或恢复检查 |
| 工具结果 | 按任务与日志政策保留 | 查询结果摘要、必要标识、错误与证据位置 | 不能默认等同于权威事实或永久记忆 |
| 持久记忆 | 仅在明确目的、权限和保留期下存在 | 已确认决定、可复用工作笔记、明确偏好 | 不能保存未经确认的推测、敏感原文或跨用户信息 |
事实、假设和待核验项必须分开记录。 例如，Coding Agent 的工作笔记可以记录“测试未通过，待人工确认原因”；但不应把“某模块应由某团队负责”写成永久事实，除非其来源、责任人和适用范围已经确认。
三、构建最小上下文包
1. 上下文包的定义
上下文包（Context Pack）：在特定任务、状态和权限下，允许进入模型推理的最小必要信息集合。它说明“要解决什么、允许看什么、为什么看、看多少、谁负责、何时失效、出错时如何停止”。
上下文包不是一次性的长 Prompt，也不是全部企业资料的压缩版。它是可版本化的运行资产，应与用例立项、Skill 卡、工作流合约、Agent 运行合约和评测记录关联。附录A的“上下文包卡”模板可用于正式记录。
| 字段 | 必须说明的内容 |
|---|---|
| 用途与任务 | 本次任务要支持的业务问题、对象、输出和不可接受后果 |
| 允许来源 | 权威知识、文件、系统、工具或记忆的白名单，以及来源优先级 |
| 排除来源 | 不应读取、保存、外发或作为依据的内容，例如未批准资料、敏感字段、旧版本 |
| 选择逻辑 | 哪些字段预置；何时按需检索；冲突、空结果或低置信时如何处理 |
| 内容预算 | 文件、字段、返回量、步骤或 token 的上限；必要时采用分页、过滤或摘要 |
| 数据与权限 | 数据分级、读取范围、保存位置、外发限制、使用者与 Agent 权限 |
| 版本与 Owner | 上下文包版本、知识/工具/记忆版本、业务 Owner、知识 Owner、技术 Owner |
| 证据与失效 | 来源位置、核验日期、失效条件、回退路径和受影响评测样本 |
2. 从资料到上下文包的五步法
- 先定义任务，而不是先搜资料。 明确任务对象、输出、决定边界、人工责任和停止条件。
- 建立来源白名单。 列出本任务允许使用的权威知识、工具和记忆；不确定来源只可作为待核验线索。
- 只预置不可缺少的信息。 例如固定规则、输出契约、当前对象标识、必要安全边界和少量规范示例。
- 将其他信息改为按需获取。 通过受控检索或工具按问题、时间、对象和权限逐步加载，而不是预先加载整个库。
- 保留证据并测试失败路径。 测试空结果、冲突规则、过期知识、权限拒绝、工具超时和异常输入时，系统是否停止、转人工或回退。
3. 示例：客户咨询回复的最小上下文包
用途：为授权审核者生成客户咨询回复草稿；不自动发送、不作例外承诺。
预置：回复结构、禁止承诺、转人工条件、当前问题类别、审核要求。
允许知识：知识 Owner 批准且带版本、生效日期和适用范围的规则条目。
按需检索：仅检索当前问题类别、地区、产品和生效期对应的条目。
排除：历史失效规则、未批准补偿口径、完整客户画像、与当前问题无关的内部材料。
工具结果：只返回与问题相关的字段、来源ID和生效日期；空结果或冲突时转人工。
记忆：不保存客户原文或未确认承诺；仅在批准的业务系统按政策保留必要审核记录。
人工控制：审核者查看来源、版本、适用范围和草稿后决定采用、修改、拒绝或转人工。这个示例说明：最小上下文包既减少噪音，也使审核者能判断“系统为什么这样回答”。对外沟通、高影响决定、敏感数据或工具写入任务，应提高来源、权限、审批和运行证据要求。
四、知识、检索、记忆与工具结果如何配合
企业不应把“放不下就上 RAG”当成唯一升级路径。不同机制解决的是不同问题，可以组合使用。
| 机制 | 主要解决的问题 | 优点 | 必须控制的风险 |
|---|---|---|---|
| Prompt 与固定参考材料 | 少量稳定规则、格式、角色与输出要求 | 快速、透明、便于起步 | 规则堆叠、过期、上下文过长 |
| 引用文件或结构化上下文包 | 当前任务的少量明确资料 | 来源清楚、易审核 | 文件版本、权限、范围与最小必要性 |
| RAG | 大量文档中的相关权威片段检索 | 可按任务返回相关内容 | 检索偏差、过期索引、引用缺失、权限过滤不足 |
| Agentic retrieval | Agent 在受限工具和路径中逐步定位所需资料 | 适合复杂探索和长任务 | 搜索死角、无效循环、越权检索、过度加载 |
| 工具生成的上下文 | 获取实时状态、系统记录或确定性计算 | 及时、可执行、可减少模型猜测 | 参数错误、返回污染、过长输出、工具可信度与权限 |
| 持久记忆与压缩摘要 | 跨轮次维持经过确认的决定、待办和进度 | 支撑长任务连续性 | 错误写入、失效、跨用户混用、不可删除 |
| 微调 | 固化格式、风格或重复行为模式 | 有助于一致性 | 不适合承载频繁变化的事实、政策或权限判断 |
对于多数起步用例，推荐顺序仍是：先用最小上下文包和固定工作流跑通闭环；知识规模、任务动态性或运行时效确实需要时，再逐步增加检索、工具或记忆。RAG、Agentic retrieval 和微调都不是质量保证；它们改变信息进入模型的方式，仍需使用真实任务样本、来源归因、人工审核和回归评测证明其价值。
1. 按需检索优于全量灌入
上下文工程的公开实践建议，在长任务或大规模资料场景中保留轻量索引，通过文件路径、查询、链接或其他引用按需发现内容，而不是预先加载全量对象；这能保持工作记忆聚焦，但需要为 Agent 提供清晰的工具、命名、范围和启发式规则。1
对企业的最低要求是：检索工具应支持过滤、范围限制、分页或截断；返回内容应包含能支持下一步判断的高信号字段与来源，而非默认返回整库内容。工具职责、参数和错误信息越清楚，Agent 越容易在合法范围内正确使用它。2
2. 记忆与压缩不是无损存档
长时任务可以使用压缩历史、结构化工作笔记或受限子 Agent 等方式保持连续性，但必须明确：什么可以保留、谁可以写入、何时过期、如何纠错、是否跨用户隔离、重新读取时怎样定位原始来源。
| 情形 | 可采用的方式 | 最低控制 |
|---|---|---|
| 长会话接近上下文限制 | 压缩为带来源的任务摘要 | 保留关键决定、未解决项、版本和证据位置；不把摘要当作原始事实替代品 |
| 多步骤项目推进 | 结构化工作笔记或任务状态 | 区分事实、假设、待确认项；限制写入人和读取范围 |
| 复杂研究或代码库探索 | 子 Agent 处理局部探索，返回浓缩结果 | 隔离子任务上下文；主 Agent 只接收必要结论、来源和不确定项 |
| 跨用户服务 | 默认不共享个人或客户记忆 | 以身份、租户、数据分级和明确目的隔离；提供删除与失效路径 |
五、上下文变更、记忆治理与回归
知识变更不是“改完文档就结束”，上下文变更也不是“换了一个检索器或模型就结束”。任何规则、工具、记忆、权限、索引、提示、状态机或选择逻辑的变化，都可能影响已运行的 Skill、工作流或 Agent。
| 变化类型 | 例子 | 最低动作 | 发布方式 |
|---|---|---|---|
| 低风险表达优化 | 修正错别字、统一术语、改进不影响结论的工具描述 | 记录版本与原因；抽样检查 | 常规维护窗口 |
| 中风险上下文调整 | 新增示例、优化检索过滤、修改摘要模板、调整工具返回字段 | 分析受影响任务；回归正常与边界样本；确认来源和权限未变化 | 限量试运行或由 Owner 确认后发布 |
| 高风险规则或动作变化 | 政策/价格/合同变化、数据范围扩大、新工具/连接器、记忆跨域、写入权限或审批变化 | 确认权威来源与生效时间；完成风险审查、影响分析、正常/边界/失败样本回归、审批和观察期 | 先离线回归，再限量发布；保留上一稳定版本与人工回退 |
任何变更都应回答六个问题：什么变了？为什么变？影响了哪些上下文包、Skill、工具、记忆和用例？哪些样本必须回归？谁批准恢复或扩大？出问题时回退到哪里？
对规模较小、低风险的内部 Skill，这个过程可以很轻：知识 Owner 更新条目，使用者用代表性样本验证，再记录版本即可。对外沟通、高影响决定、多个团队共用知识、跨系统工具或持久记忆，则必须提高证据、审批和隔离要求。
六、评测上下文，而不只评测最终答案
“检索命中”或“Agent 完成任务”都不足以证明上下文设计可用。正式评测应同时检查：系统是否取得了正确的信息、是否在正确范围内使用、是否清楚展示依据、是否在不确定时停止，以及最终任务是否满足业务标准。
| 评测层 | 要验证的问题 | 代表性样本或证据 |
|---|---|---|
| 来源与权限 | 是否只读取允许来源；是否拒绝越权或敏感材料 | 权限拒绝、跨区域、跨客户、未批准文件 |
| 检索与选择 | 是否检索到正确规则、范围和版本；是否避免无关内容 | 正常、冲突、过期、信息不足、相近但不适用问题 |
| 工具与返回 | 工具参数、返回量、错误处理和来源是否适合任务 | 空结果、超时、长返回、参数错误、恶意或错误返回 |
| 记忆与状态 | 是否区分已确认事实、假设和待办；是否正确失效或恢复 | 会话压缩、任务中断、跨用户、规则变更、人工纠正 |
| 任务与业务结果 | 最终输出、行动建议或受控动作是否满足 Rubric | 真实去标识化历史任务、边界、失败与异常样本 |
| 人工接管与回退 | 失败时是否能看懂依据、停止并恢复业务 | 审批拒绝、知识冲突、工具不可用、预算或步骤限制触发 |
建议在健康卡和回归报告中按用例记录：来源可定位率、过期/冲突上下文拦截情况、权限拒绝是否正确、工具错误率、上下文或工具成本、人工接管率、以及最终任务质量。指标的阈值应由业务影响、基线和风险边界确定，不应复制其他团队的固定数字。
七、本章行动清单
员工与知识 Owner
- [ ] 为正在使用的一个 Skill 写出最小上下文包：任务、允许来源、排除来源、版本、生效范围、人工责任和停止条件。
- [ ] 检查当前资料中是否存在无 Owner、无日期、无来源、互相冲突或不应被当前任务读取的内容。
- [ ] 将运行中发现的问题先标记为“待核验线索”，不要直接写入权威知识或持久记忆。
- [ ] 对需要外发、写入或高影响判断的任务，确保审核者能够看到来源、范围和不确定项。
业务 Owner、技术 Owner 与 Agent 负责人
- [ ] 为每个正式 Agent 确定上下文来源白名单、工具白名单、记忆策略、读取/写入权限和失效条件。
- [ ] 将知识、检索、工具、状态或记忆变更接入影响分析、Golden Set、回归报告和发布登记。
- [ ] 用空结果、过期资料、冲突规则、越权请求、工具超时和人工审批拒绝测试停止与回退。
- [ ] 在附录A中建立上下文包、记忆和工具控制记录；将已验证资产交给可接棒的 Owner 维护。
八、本章小结
数据、知识与上下文共同构成企业 AI 稳定产出的运行底座。其质量不只取决于“资料是否正确”，还取决于：当前任务为何需要这些信息、其来源和版本是否可追溯、是否在权限内、是否足够且不过量、能否在变化后回归并在失败时停止。
固定工作流需要可靠上下文，Agent 更需要可靠上下文。推荐的升级顺序是：先准备最小上下文包并跑通受控 Skill；再把知识、检索和工具作为可验证组件接入固定工作流；只有在动态编排确有价值、并且状态、权限、评测、接管和审计条件齐备时，才让 Agent 在有限范围内使用这些资产。下一章将把这一运行底座转化为可执行的最小闭环设计。