从业务样本而不是功能愿望开始
针对“知识库能检索制度，却不了解当前业务对象和实时状态”，项目启动前抽取不同用户、时间段和异常类型的代表性任务，复原从输入到结果的完整路径。访谈内容与系统日志交叉核对，区分事实、推断和待验证项。对没有数据支撑的判断，先设计采集办法，不把主观感受直接写成项目收益。
例如可以抽取连续20个工作日的任务，记录数量、角色、处理时长、等待节点、返工原因和最终状态。样本量是否足够取决于业务波动与风险，不采用一个“通用正确数字”。
C级 · 能力场景示例
适用于RAG已经能够回答资料问题，但AI仍不了解当前客户、订单、项目、权限和任务状态，导致结果与业务现场脱节的企业。本页为C级能力场景。 本页不主张已完成某个特定客户项目，也不使用未经授权的客户名称、业绩或经营数据。了解案例证据分级
典型业务挑战
知识库能检索制度，却不了解当前业务对象和实时状态
长提示堆入大量资料，成本高且重要信息容易被淹没
不同系统字段、身份和时间有效性没有统一上下文契约
任务中间状态只存在会话，跨步骤和人工接管后丢失
无法还原一次结果使用了哪些知识、数据和工具
方案设计思路
01
选择销售准备、客服处理或项目交付中的真实岗位任务
02
定义任务需要的静态知识、实时数据、身份、状态和工具
03
按任务阶段动态装配最小充分上下文并标记来源与有效期
04
在工具调用前校验权限和参数，高风险动作保留人工审批
05
保存上下文快照、输出、修改和任务结果用于评测复盘
06
依据失败样本持续优化上下文选择、顺序、压缩和更新
知华可承担的项目职责
复原岗位任务及所需知识、数据、系统和人工判断
设计上下文契约、装配策略、权限和生命周期
开发工作台、连接器、工具调用、状态和审计能力
用真实任务验证上下文完整性、有效性、成本和结果质量
实施约束与能力边界
01
上下文工程不能修复错误的源数据、混乱权限和不清晰业务责任
02
长期记忆必须明确用途、授权、保留时间和用户纠正方式
03
并非上下文越多越好，应围绕任务选择最小充分信息
04
实时系统接口和知识更新状态会直接影响结果时效性
系统能力范围
岗位任务入口上下文目录与契约知识和实时数据装配身份权限继承任务状态与记忆工具调用与审批上下文追溯任务质量评测
可交付成果
PROJECT OUTPUT岗位任务和上下文需求地图
PROJECT OUTPUT上下文数据契约与权限设计
PROJECT OUTPUT任务工作台和上下文编排源码
PROJECT OUTPUT知识、实时数据及工具连接器
PROJECT OUTPUT上下文快照、审计与评测机制
PROJECT OUTPUT部署运营和持续优化手册
应形成的工程证据
作为C级能力场景，本页不声称已持有某个客户的项目证据。类似项目实施后，应按合同范围形成以下可核验材料。
VERIFIABLE EVIDENCE岗位任务、业务对象、上下文来源和责任人清单
VERIFIABLE EVIDENCE字段、时间有效性、权限、版本和异常处理契约
VERIFIABLE EVIDENCE正常、缺失、过期、冲突和越权任务评测记录
VERIFIABLE EVIDENCE上下文快照、工具调用、人工修改和结果审计日志
VERIFIABLE EVIDENCE上下文长度、延迟、成本和质量对比报告
VERIFIABLE EVIDENCE源系统异常、模型不可用和人工接管演练材料
建议写入合同的验收标准
任务需要的关键知识、实时数据和身份在正确阶段出现
过期、冲突、缺失和越权上下文按规则拒绝或转人工
每项关键结论和系统动作能够回到上下文来源核对
上下文装配后的任务质量、延迟和成本达到约定基线
工具调用使用当前用户或服务身份并执行正确审批
企业人员能够维护上下文契约、连接器和评测任务
CAPABILITY CASE WALKTHROUGH
能力场景如何落到项目计划
本段继续采用C级能力场景口径，数字为估算方法示例，不代表任何特定客户成果。
将系统能力映射到具体责任
场景中的岗位任务入口、上下文目录与契约、知识和实时数据装配、身份权限继承不会作为孤立模块堆叠，而要对应到业务角色、数据来源、操作权限和异常处理。每个关键状态定义谁创建、谁确认、什么条件可以流转、失败后如何恢复，并明确客户业务团队与实施团队各自负责的资料、审批和系统环境。
原型评审使用真实字段和代表性流程。涉及第三方系统时，在排期前核对接口文档、测试账号、调用限制和联调负责人；无法确认的依赖单列风险，不在开发后期才暴露。
正常、异常和边界任务都要覆盖
验收集至少包括标准流程、字段缺失、重复提交、越权访问、外部接口失败、数据冲突和人工退回。建议形成岗位任务、业务对象、上下文来源和责任人清单、字段、时间有效性、权限、版本和异常处理契约、正常、缺失、过期、冲突和越权任务评测记录，让每条验收结论能够回到需求、版本、执行记录和最终结果。
若场景包含AI能力，还需固定评测问题、期望结果、引用依据和拒答规则；若包含交易或数据同步，则重点验证幂等、对账、补偿与回滚。
示例数据只用于建立测量方法
假设改造前每周有300项任务、平均完成周期2.5天、人工追问率25%，可以把目标写成“首期上线六周后，在任务复杂度相近的前提下，平均周期下降20%，追问率不高于15%，关键数据完整率达到98%”。这些数字必须在正式项目中由双方依据基线重新确认。
合同验收可重点核对任务需要的关键知识、实时数据和身份在正确阶段出现、过期、冲突、缺失和越权上下文按规则拒绝或转人工、每项关键结论和系统动作能够回到上下文来源核对。业务指标未达到时，需要区分系统缺陷、数据条件、流程执行或外部依赖，不把全部问题简单归因于技术。
DECISION FAQ
查看全部243个问题 →与当前项目相关的常见问题
企业上下文工程、模型迁移与流程智能
企业上下文工程和RAG知识库有什么区别？
RAG重点解决如何从知识库找到相关资料并提供给模型；企业上下文工程的范围更大，还要组织当前用户身份、结构化业务数据、实时状态、长期记忆、业务规则和可用工具。只有文档问答时，RAG通常足够。涉及跨系统任务、不同角色权限和连续工作时，需要把RAG放进完整上下文链路中设计。
查看完整回答 →企业上下文工程、模型迁移与流程智能企业做Agent上下文工程需要准备哪些数据和系统？
先准备首期任务的用户角色、真实输入输出、知识来源、业务对象、系统接口、权限和历史处理记录，不需要一开始汇总全公司的全部数据。关键不是数据数量，而是能否说明每项信息由谁维护、何时有效、谁可以访问以及错误时如何纠正。首期应选择一条资料和责任相对清楚的业务闭环。
查看完整回答 →AI咨询、MCP集成、技术外包与系统运维MCP连接企业内部系统，怎样控制数据和操作权限？
不要让所有Agent共享一个拥有全部权限的服务账号。MCP工具应尽量透传用户身份或使用限定服务身份，并按用户、角色、数据范围和具体动作授权。查询、建议、创建草稿和正式提交要区分风险等级。敏感写入还应增加审批、幂等、审计、速率限制和紧急停用能力。
查看完整回答 →AI数据治理与销售智能应用什么是AI就绪数据，企业应该怎样验收？
AI就绪数据不是“已经放进数据库”的数据，而是对目标任务足够完整、及时、授权、可解释并能持续更新的数据。验收需要同时检查业务对象、字段和文档质量、来源版本、角色权限、无答案与冲突处理，以及真实任务上的效果。还要确认训练、验证和测试数据彼此独立，避免只在已见样本上表现良好。最终应能说明数据变化后怎样重新处理和回归。
查看完整回答 →