最初讨论 AI 助手时，很容易把目标理解成“在系统里增加一个聊天窗口”。但真正开始落地后会发现，聊天只是最表层的交互。
用户真正需要的不是另一个搜索框，而是一个能够理解当前环境、找到正确答案、查询实时信息，并把结果带回业务流程的协作者。
因此，落地的重点并不是如何调用模型，而是如何让模型在产品边界内可靠工作。
我们最终想做成什么
理想中的业务助手应该是产品的一层统一交互界面，而不是一个孤立页面。
用户可以从不同位置发起需求：直接提问、使用快捷入口，或者把当前看到的内容交给助手继续处理。助手能够理解用户所处的页面和当前意图，然后在三类能力中选择合适的处理方式：
- 使用产品知识回答问题；
- 在权限范围内查询实时数据；
- 将自然语言整理成可供业务模块使用的结构化结果。
最终效果可以概括为：
1用户表达意图 2 ↓ 3助手理解当前上下文 4 ↓ 5知识回答 / 实时查询 / 配置整理 6 ↓ 7结果回到原有业务流程 8 ↓ 9用户确认重要操作
这里最关键的一点是，助手不会取代业务系统。
权限校验、数据约束和最终执行仍然由原有系统负责。助手只承担理解、组织和衔接，让用户少找入口、少读说明、少重复填写。
目前做到哪一步
当前版本已经完成了从“聊天”到“业务协作”的基础闭环：
- 不同入口可以汇入同一套对话体验；
- 助手能够结合产品知识和当前页面理解问题；
- 动态信息通过受控工具查询，而不是由模型猜测；
- 自然语言可以整理成经过校验的结构化结果；
- 结果能够回到已有业务模块，并由用户确认后继续执行；
- 回复过程支持流式反馈、停止、失败提示和重试。
这意味着它已经不只是一个演示型聊天窗口，但仍然不是能够独立完成长流程的全自动 Agent。当前形态更接近“有边界的业务协作者”。
当前选择了怎样的架构
实现上将系统分为交互层、可信业务层和 AI 编排层，知识、工具与模型作为编排层依赖的能力资源：
1┌──────────┐ 2│ 用户 │ 3└────┬─────┘ 4 │ 5 ▼ 6┌──────────┐ 7│ 交互层 │ 8└────┬─────┘ 9 │ 用户输入与页面上下文 10 ▼ 11┌──────────────┐ 12│ 可信业务层 │◀──────────────┐ 13└──────┬───────┘ │ 14 │ 可信身份与受控请求 │ 受权限约束的查询 15 ▼ │ 16┌──────────────┐ ┌───────┴──────┐ 17│ AI 编排层 │───────▶│ 受控工具 │ 18└───┬──────┬───┘ └──────────────┘ 19 │ │ 20 ▼ ▼ 21┌────────┐ ┌────────┐ 22│产品知识│ │ 模型 │ 23└────────┘ └────────┘ 24 25流式结果：AI 编排层 → 可信业务层 → 交互层
交互层：管理体验，不建立信任
交互层负责接收输入、携带有限的页面上下文、展示流式回复，并把结构化结果呈现为可确认的操作。不同入口最终都会汇入同一套对话状态，避免每个页面各自维护一套助手逻辑。
这一层提供的是用户体验，而不是安全依据。浏览器提交的身份、权限或目标数据都不能直接被内部能力信任。
可信业务层：连接账号体系与 AI
可信业务层沿用原有登录和权限体系。它校验公开请求，从服务端上下文中取得当前用户身份，再生成发送给 AI 编排层的可信请求。
它还承担两个方向的适配：向内隐藏公网协议和浏览器细节，向外隐藏内部服务、模型和工具的实现。Agent 需要查询动态数据时，也必须通过这一层回到正常业务权限体系，而不是直接访问数据源。
AI 编排层：决定本轮需要什么能力
AI 编排层管理对话 Session，并根据当前问题组合必要上下文。它会先选择相关产品知识，再判断是否需要调用白名单工具，最后将模型文本、处理状态和结构化结果统一转换成流式事件。
模型只是编排层中的一个依赖。知识检索、工具权限、会话生命周期和结果校验都由普通代码控制，不依赖模型自行遵守一段提示词。
一次请求如何流转
一轮对话大致经过以下过程：
- 交互层提交用户输入、对话标识和经过裁剪的页面上下文。
- 可信业务层完成登录校验，并补充服务端确认的身份和权限信息。
- AI 编排层取得或创建当前会话，检索与问题相关的产品知识。
- 如果需要实时数据，编排层调用限定工具；工具仍通过可信业务层执行权限校验。
- 模型基于当前问题、少量相关知识和工具结果生成回复。
- 文本、状态或结构化结果沿原链路持续返回交互层。
任何一层失败，都只向上一层返回约定好的错误，不把内部异常、模型信息或工具参数直接暴露给浏览器。
这不是最少代码的方案，却是职责最清晰的方案。
如果浏览器直接连接模型，身份和工具权限很难形成可靠边界；如果所有能力都堆进业务服务，模型运行时、知识更新和普通业务逻辑又会彼此干扰。将 AI 编排独立出来后，模型或检索方案可以替换，业务权限不需要随之重写，前端也不必了解内部变化。
为什么不把所有知识都写进提示词
系统早期最简单的做法，是把产品说明全部塞进系统提示词。但随着页面和规则增加，这种方式会快速失控：
- 每次请求都携带大量无关内容；
- 产品变化后很难知道应该修改哪里；
- 不同角色可能看到不属于自己的说明；
- 内容无法独立校验和测试。
当前方案将产品知识作为结构化内容单独维护，在构建时完成校验，在对话时只取与当前问题相关的少量内容。
现阶段没有引入复杂的向量检索基础设施。原因并不是否定它，而是当前知识规模仍然可控，确定性、可审查性和低维护成本更重要。轻量检索足以解决主要问题，也更容易判断一次回答究竟引用了什么。
当知识量、表达差异和跨文档关系继续增长时，再评估更复杂的检索方案会更合理。
为什么要把“能力”做成结构化协议
普通问答可以返回自然语言，但业务配置不能只依赖模型输出一段看起来像 JSON 的文本。
当前设计要求用户先明确选择能力，服务端再限制本轮可使用的工具。工具返回经过约束的结构化结果，前端校验通过后，才允许用户将它应用到对应业务模块。
这样做的原因有三个：
- 避免普通聊天意外触发业务操作；
- 避免模型自行决定目标页面或执行范围；
- 让结构化结果可以被类型、测试和前端组件共同约束。
即使配置已经生成，也不会自动执行重要操作。用户仍然需要回到业务界面核对并确认。
这让助手更像一个可靠的准备者，而不是拥有无限权限的自动驾驶系统。
为什么保留流式响应
AI 请求的耗时不可预测。如果只能等待完整结果，用户很难判断系统是否仍在工作。
流式响应可以及时展示思考、检索、工具调用和文本输出等阶段，也允许用户中途停止。它带来的额外复杂度是前端必须维护明确状态，而不能只是不断拼接字符串。
当前选择流式方案，是在响应体验和实现复杂度之间的折中。它比轮询更及时，也比维护一套双向长连接协议更轻量，适合以“用户发起一次请求、服务端持续返回结果”为主的交互。
安全边界是如何确定的
这套设计遵循几个简单原则：
- 浏览器不能声明自己的真实身份和权限；
- 模型不能直接访问数据库或任意内部服务；
- 工具只能使用业务服务提供的可信上下文；
- 模型输出在展示和执行前都要再次校验；
- 内部错误、提示词、供应商信息和凭据不会返回给用户；
- 涉及重要状态变化的操作必须由用户确认。
这些限制会牺牲一部分“无所不能”的感觉，却能让助手真正进入生产系统。
一个助手能做多少事情并不是最重要的，重要的是系统能否明确解释：它为什么能做、可以替谁做、做到哪一步，以及谁来承担最终确认。
当前形态还缺什么
目前的设计已经打通了问答、知识、实时工具和结构化结果，但距离更成熟的形态仍有几块需要补齐。
1. 更系统的知识治理
知识已经可以结构化维护，但还需要术语规范、内容负责人、过期检查和变更审阅机制。否则条目数量增加后，仍然可能出现重复、冲突和旧规则残留。
2. 可重复的回答质量评估
现有自动化测试主要保证权限、协议和数据结构不会越界。下一步还需要建立典型问题集，持续评估知识命中、回答正确性、引用完整性和拒答表现。
3. 多实例会话能力
轻量的内存会话适合当前阶段，但在多实例部署、滚动发布或长周期对话场景中，需要进一步考虑共享会话、会话迁移和一致性问题。
4. 更完整的失败降级
模型、知识服务或实时工具不可用时，助手应该有明确的降级路径，例如返回基础帮助、引导用户进入对应模块，或允许稍后重试，而不是只有一个统一错误提示。
5. 用户反馈闭环
系统还需要知道哪些回答真正解决了问题、哪些配置被用户修改、哪些建议最终被采用。只有建立反馈闭环，才能判断应该优化知识、工具还是交互。
6. 更长流程的协作能力
当前助手更擅长单轮查询和一次配置整理。未来如果要支持多步骤业务流程，需要引入更明确的任务状态、阶段确认、可恢复执行和操作审计，而不是简单增加提示词长度。
这套路线的取舍
这套实现没有追求一步做到完全自动化，而是优先解决三个问题：
- 可信：身份、权限和执行边界不交给模型判断。
- 可控：知识、工具和结构化结果都能被代码验证。
- 可演进：模型、检索方式和业务能力可以分别替换。
如果只是做演示，浏览器直接调用模型并准备一段长提示词会更快。但当助手需要进入真实业务系统时，身份边界、知识治理、工具权限和用户确认迟早都要补上。当前方案选择先建立这些基础能力，换取后续演进时不必反复推翻底层结构。
结语
业务型 AI 助手的最终形态，不是一个回答所有问题的聊天窗口，而是一层能够理解上下文、连接知识与工具、并尊重业务边界的交互入口。
当前实现只是其中一个阶段：它已经从“聊天”走向“协作”，但还需要知识治理、质量评估、会话基础设施、失败降级和反馈闭环，才能逐渐成为稳定的产品能力。
真正值得投入的并不是让助手显得更聪明，而是让它在知道什么、能做什么和不能做什么这三件事上越来越可靠。
cd ..