AI 协作的关键，是把执行边界说清楚

一个 Agent 能描述操作步骤，不代表它已经得到修改业务数据的授权。它能调用接口，也不代表模型应该决定用户身份、目标对象和审批结果。把“会做”与“可以做”分开，是让 AI 参与真实业务的起点。

知识回答与实时业务状态是两类问题

操作手册、产品规则和字段解释可以来自经过审核的知识库。查询时应带上当前用户的权限，只返回可访问、已发布且有原文引用的内容。待办状态、账号信息或审批结果则随时变化，应由对应业务服务返回，不适合被长期知识文本当成实时事实。

在 LFN Cloud 的设计里，knowledge_search 是受控的只读入口。Agent 可提出问题和检索模式，知识服务仍决定允许访问的空间与证据范围。模型给出的文字是一种建议，不能因为它写得肯定，就变成系统授权。

写操作把决定权还给用户

如果对话最终要执行审批等操作，流程应该先补齐业务字段，调用业务接口做预校验，然后展示具体动作、对象和参数。用户确认的是这一份预览；参数改变后，旧确认不再有效。真正执行时还需用当前用户身份重新鉴权，并由业务服务再次检查状态和权限。

执行后也不能只凭“请求已发出”就宣布成功。网络超时可能意味着操作已经完成，也可能没有完成。此时需要稳定的请求标识，查询或恢复同一动作，而不是创建一笔新操作。界面应该把这种未知状态展示出来，直到能核对实际业务结果。

协作是可解释的过程

用户需要知道 Agent 引用了什么、缺少哪些参数、准备调用哪个动作，以及结果从哪里得到验证。这些停顿和确认看似让流程多走了几步，却使错误更容易被发现和修正。

当前项目已有知识检索、工具白名单、预览确认与结果恢复的代码链路。真实模型语义判断、跨服务联调和复杂业务表单仍需要继续验证；这些验证会决定哪些能力适合逐步开放。