#状态、上下文与工具边界

#1. 提出问题

一个企业内部的“销售跟进助手”可以读取 CRM 客户资料、总结历史沟通、生成下一封邮件、查询合同状态，并在销售确认后创建跟进任务。产品希望它像一个持续协作的工作台，而不是一次性聊天机器人。

用户会说：

帮我看一下星河科技最近的沟通记录，按上次 CTO 关心的安全问题写一封跟进邮件。如果合同已经到法务，就不要催价格，改成问他们是否需要补充安全材料。

这个请求里同时出现了客户状态、历史上下文、知识片段和工具动作。模型需要理解自然语言，但它不应该凭聊天记录判断合同真实状态，也不应该直接创建任务或发送邮件。

问题不是“上下文放多少”，而是三类信息边界如何划清：

• 状态：系统需要长期保存并可审计的事实，例如客户阶段、合同状态、任务状态、用户确认结果。
• 上下文：本次模型调用为了理解和生成而临时提供的信息，例如相关沟通摘要、知识片段、当前页面对象。
• 工具：模型读取或改变外部系统的受控能力，例如查询合同、创建跟进任务、发送邮件预览。

如果这三者混在一起，系统会把 prompt 当数据库、把模型记忆当事实、把工具调用当权限控制，最终很难恢复和复盘。

#2. 分析问题

销售跟进助手包含多类任务：

状态、上下文和工具各有不同的工程属性。

模型可以帮助生成摘要和建议，但不能成为唯一事实来源。比如“合同已到法务”应该来自合同系统工具或 CRM 状态，而不是来自用户一句模糊描述或历史摘要。模型可以建议“创建跟进任务”，但创建动作应该经过工具运行时和用户确认。

收益来自连续性和自动化：减少销售查资料的时间，让跟进更及时，让客户信息更容易被复用。风险在于错误会累积：错误状态会污染后续推荐，错误上下文会误导当前输出，错误工具调用会改变真实业务系统。

#3. 列举方案

可以按边界清晰度逐级升级。

第一层是一次性聊天上下文。适合临时写作、润色、总结，状态不需要跨会话保存，工具也不参与。

第二层是最近消息 + 页面状态。模型能看到当前客户页面、用户刚输入的约束和最近几轮对话。适合低风险的摘要和草稿。

第三层是结构化业务状态。客户阶段、合同状态、待办、用户确认、工具结果等进入数据库或工作流状态，而不是留在自然语言历史里。它适合需要恢复和审计的业务流程。

第四层是检索式上下文。历史邮件、会议纪要、知识库和过往任务不全部塞入 prompt，而是按当前问题检索、排序、引用和权限过滤。

第五层是工具读取边界。模型可以请求查询合同、客户、订单或知识库，但工具运行时必须做鉴权、参数校验、脱敏、超时和结构化错误。

第六层是工具写入边界。创建任务、写 CRM、发送邮件、发起审批这类动作必须有预览、确认、幂等、审计和必要的回滚或补偿。

第七层是状态机 / 工作流。稳定多步骤流程，例如“生成邮件草稿 -> 销售确认 -> 创建任务 -> 记录跟进 -> 主管复核”，应该用状态机表达，而不是让模型每轮从聊天里猜下一步。

第八层是 Eval + Ops。评估上下文命中率、状态污染率、工具错参率、人工确认通过率、重复写入率、成本和延迟。

简单 prompt 足够的条件是：任务一次性完成、输出只是草稿、用户会编辑、没有外部系统读写。prompt 不再足够的信号是：需要跨会话继续、需要可信业务事实、需要访问私有数据、需要写入系统、需要恢复和审计。

#4. 决策判断

三个边界要分别判断。

第一，状态边界：凡是会影响后续业务决策、需要跨会话恢复、需要审计或会被多个系统消费的信息，都应该作为状态保存。状态要有来源、时间、版本和责任人。

第二，上下文边界：进入 prompt 的只是本次调用需要的最小可信信息。上下文要标记来源和时间，先做权限过滤，再做压缩和排序。

第三，工具边界：模型可以提出工具调用意图，但运行时决定是否允许执行。读取工具要防越权和误读，写入工具要防错参、重复副作用和不可逆动作。

常见反模式：

• 把聊天历史当状态库，导致任务失败后无法恢复。
• 把模型摘要当事实来源，后续建议基于未经确认的推测。
• 先检索所有资料再让模型“自己判断哪些有用”，造成成本高、越权和幻觉。
• 工具返回自然语言，模型误把“未找到合同”解释成“合同还没开始”。
• 写入工具没有幂等键，用户刷新或重试后重复创建任务。
• 用 prompt 要求模型“不要访问无权限客户”，但权限过滤发生在上下文组装之后。

#5. 结论收束

状态、上下文和工具的边界，是 LLM 应用能否长期运行的基础。状态负责长期事实和流程恢复，上下文负责当前模型调用的最小信息，工具负责受控读取和执行。三者混在 prompt 里，短期看似灵活，长期会让质量、权限和事故复盘都失控。

最低可上线版本应该先做到：业务状态结构化保存，当前调用上下文可追溯，工具只读优先，写入必须确认和审计。只有当任务路径确实动态且有充分评估、权限和回滚机制时，再考虑更开放的 agent。

上线前检查项：

• 状态定义：哪些信息是业务状态，schema、来源、更新时间和责任人是否明确。
• 上下文选择：本次调用需要哪些信息，是否有来源、时间、权限和优先级。
• 权限过滤：是否在检索和上下文组装前完成，而不是生成后补救。
• 检索证据：历史沟通、知识库和工具结果是否可引用、可追溯。
• 工具契约：读取和写入工具是否分开，input、output、error schema 是否稳定。
• 写入保护：创建任务、发送邮件、改 CRM 是否有预览、确认、幂等和审计。
• 冲突处理：用户描述、业务状态和工具结果冲突时，优先级和人工入口是否明确。
• 可观测性：是否记录状态快照、上下文摘要、工具调用、确认记录和模型输出。
• 评估体系：是否覆盖上下文命中、状态污染、工具错参和重复写入样本。
• 恢复回滚：错误状态或错误工具调用发生后，是否能撤销、补偿和复盘。