一、为什么越来越多人想让本地 Agent 直接操作业务后台？
过去的企业 AI 助手，大多被放在业务系统内部。
用户登录商城、CRM、ERP 或 SaaS 后台，在右下角打开一个聊天窗口，然后询问：
- 今天有哪些待处理订单？
- 哪些商品库存不足？
- 帮我查询某个员工的资料。
- 创建一个售后工单。
- 修改客户标签并记录跟进结果。
这种方式有一个天然优势：AI 对话入口本来就在业务后台里，浏览器已经有当前用户、当前租户和当前门店的登录状态。
但随着本地 Agent、桌面智能体和各种 Agent CLI 出现，用户开始提出另一个问题：
能不能不打开业务后台，直接在本地智能体里发起任务，让它帮我操作 CRM、ERP、商城或 SaaS？
这个需求并不奇怪。
企业 Agent 产品的公开资料也越来越强调 CRM、ERP、OA 和自研系统连接，以及 Agent 身份与凭证管理。腾讯云 ADP和阿里云智能体身份都把这类问题放到了企业 Agent 落地的重要位置。
真正困难的地方，不是“本地 Agent 能不能发出 HTTP 请求”，而是：
它在业务系统里究竟代表谁？能看到哪些能力？哪些操作可以直接执行？执行结果如何进入企业审计？
二、如果只是把消息转发给云端，本地 Agent 的意义并不大
最简单的做法，是让本地智能体把用户输入发送给云端中枢：
用户
-> 本地客户端
-> 云端中枢
-> 中枢里的模型理解和规划
-> 调用业务接口
-> 把最终结果返回本地
这种方案当然可以工作。
但这里的本地智能体，本质上只是一个聊天客户端。它没有真正参与任务规划、工具选择和多步执行。
如果目标只是让用户在桌面上发起一次聊天，那么开发一个普通客户端或者网页聊天入口就够了，没有必要引入复杂的 Agent 框架。
本地 Agent 真正有价值的地方应该是：
- 在本地理解用户目标；
- 根据当前上下文选择下一步；
- 调用一个工具后读取结果；
- 决定是否继续调用第二个工具；
- 在多个步骤之间保持任务状态；
- 最后组织用户可见的回答。
也就是说，真正需要放到本地的不是一个输入框，而是编排能力。
三、但把所有能力都交给本地 Agent，同样不合理
另一个极端，是把业务系统的接口、账号密码、API Key、知识库和全部工具一次性交给本地 Agent。
这样做看起来更“自主”，实际会产生一系列问题。
1. 业务凭证分散到每一台电脑
如果插件里保存的是商城管理员 Token、ERP 超级管理员 Key 或数据库密码，那么每安装一台客户端，就多了一份长期高权限凭证。
设备丢失、插件日志、配置同步和错误截图，都可能成为泄露入口。
2. 本地规则很快和中枢配置不一致
中枢里可能已经配置了：
- 当前接入方允许使用哪些工具；
- 哪些工具只对特定租户开放；
- 哪些操作需要审批；
- 哪些知识库和记忆可以进入当前会话；
- 哪些工具已经停用或升级。
如果本地客户端再复制一套，最终一定会出现两份知识、两份规则和两份工具目录。
3. Agent 看到的工具越多，不一定越聪明
一次性向模型注入几百个工具，不仅会扩大 Token 消耗，也会降低工具选择稳定性。
很多本地 Agent 上下文异常庞大，并不是用户真的输入了几万字，而是系统提示词、完整工具目录、重复治理说明和历史结果被反复注入。
4. 本地执行并不等于获得业务授权
任务发生在用户电脑上，只能说明执行位置在本地。
它不能证明：
- 当前用户属于哪个租户；
- 用户是否仍然在职；
- 当前门店是否允许修改该员工；
- 订单现在是否仍可退款；
- 这次操作是否需要人工审批。
执行位置和业务权限是两件完全不同的事。
四、更合理的分工：本地编排，集中治理，业务系统最终裁决
一个更适合企业业务系统的结构是：
用户
↓
本地 Agent
- 理解目标
- 选择工具
- 组织多步任务
- 生成最终回答
↓
BailingHub 一类治理中枢
- 绑定业务身份
- 提供当前上下文
- 裁剪可用能力
- 执行审批、幂等和审计
↓
业务系统
- 校验租户与用户权限
- 校验实时业务状态
- 决定操作是否最终成立
三层各自负责不同问题。
| 层次 | 主要职责 | 不应该承担的职责 |
|---|---|---|
| 本地 Agent | 理解、规划、工具选择、多步编排、最终回答 | 不能自己生成业务身份、审批结果或最终权限 |
| 中枢 | 身份绑定、上下文、能力裁剪、治理、审计 | 不能替业务系统判断实时业务规则 |
| 业务系统 | 用户、租户、数据状态和最终授权 | 不能因为前面已有 Agent 或中枢就放弃自身校验 |
这种架构不是要削弱本地 Agent，而是让它把精力集中在真正擅长的事情上：理解和规划。
五、本地 Agent 如何获得业务系统的登录状态？
答案不是读取浏览器 Cookie，也不是要求用户把业务账号密码输入插件。
更合理的方式，是由本地客户端发起一次浏览器授权。
大致流程如下：
- 用户在本地 Agent 中选择一个业务连接。
- 客户端生成临时授权请求和 PKCE 参数。
- 系统浏览器打开业务系统的授权页面。
- 用户在业务系统中正常登录，或者复用已有登录状态。
- 业务系统展示当前用户、当前租户、申请设备和申请范围。
- 用户确认授权。
- 客户端收到短期授权结果，并把刷新凭证保存到操作系统安全存储。
- 后续任务使用这条连接，而不是保存业务账号密码。
原生应用通过外部浏览器完成授权并使用 PKCE，是 OAuth 原生应用的成熟安全模式；PKCE 可以降低授权码被截获后重放的风险。RFC 8252和最新的 OAuth 安全最佳实践 RFC 9700都对这类流程给出了明确建议。
但必须注意：
PKCE 保护的是授权过程，它不会自动替企业决定业务权限。
真正的业务身份仍然必须由业务系统产生，例如当前用户、租户、门店、角色和有效期，而不能让模型在工具参数里填写一个 user_id 或 tenant_id。
六、MCP 能解决工具调用，但不能自动解决业务身份
很多开发者会问：
既然本地 Agent 已经支持 MCP，是不是把业务接口做成 MCP Server 就完成了？
还没有。
MCP 可以解决工具如何被发现、描述和调用。它的 HTTP 授权规范也提供了传输层的 OAuth 授权机制。MCP Authorization 规范明确把这一部分定位为客户端访问受保护 MCP Server 的传输层授权。
但从企业业务接入角度看，仍然要继续回答：
- MCP 登录用户如何映射到业务系统用户？
- 当前用户属于哪个租户和门店？
- 同一个 MCP Server 面向不同企业时如何隔离？
- 修改员工和停用员工是否使用相同审批规则？
- 业务系统如何在执行瞬间重新校验权限？
- 调用超时但业务可能已经成功时，Agent 能不能再次提交？
因此，MCP 可以成为工具接入层，但不能单独成为业务治理事实源。
七、中枢已经配置的知识库、路由和工具规则会不会失效？
不会，也不应该在本地再建立一套。
本地 Agent 开始一轮任务时，可以先从中枢获得一个受控的运行上下文，其中包括：
- 当前连接对应的业务工作区；
- 当前路由允许的任务范围；
- 安全指令和治理摘要；
- 与当前问题相关的知识引用；
- 当前身份可见的能力候选；
- 工具数量和风险边界；
- 当前会话需要继承的公开记忆。
本地 Agent 获得这些内容后，在本地完成推理和规划。
当它需要更多能力时，不是下载整个工具目录，而是向中枢搜索当前任务相关的能力。例如：
用户：查询某位员工的信息，并修改他的显示备注
本地 Agent 可以先搜索：
员工查询
员工详情
员工资料修改
中枢再根据当前身份、路由和能力声明，只返回这次真正相关的几个工具。
这样既保留了中枢知识库、触发路由和治理配置的价值，也避免把几百个工具全部塞进模型上下文。
八、一次“查询并修改员工资料”的任务应该怎样运行？
假设用户已经完成浏览器授权，然后在本地 Agent 中输入：
帮我找到某位员工，确认当前资料后修改他的显示备注。
合理的执行过程可以是：
第一步：建立当前任务上下文
本地 Agent 向中枢创建一轮任务。
中枢返回当前工作区、业务身份摘要、相关知识和初始工具集。
第二步：本地 Agent 选择查询工具
Agent 先调用员工列表或员工搜索能力，找到候选员工。
这一步由本地模型决定，不需要中枢再调用另一个模型替它思考。
第三步：继续查询详情
Agent 根据第一步返回的员工 ID，调用员工详情能力，确认要修改的对象。
第四步：调用修改能力
Agent 构造修改参数并提交。
中枢在真正执行前重新检查：
- 当前 Session 是否仍然有效；
- 当前用户是否仍然属于该租户；
- 当前路由是否允许该工具；
- 这项能力声明是否要求审批；
- 参数是否符合工具 Schema；
- 同一写操作是否已经提交过。
第五步：业务系统做最终授权
即便前面的检查都通过，业务系统仍然要判断：
- 当前用户是否有员工编辑权限；
- 目标员工是否属于当前门店；
- 当前员工状态是否允许修改；
- 字段是否符合业务规则。
中枢负责控制 Reach，业务系统保留最终 Authority。
第六步：记录结果并继续编排
修改成功后，本地 Agent 可以继续查询最新详情，确认结果，再向用户给出最终回答。
这才是真正的“本地 Agent 编排”，而不是本地发一句话、云端完成全部工作。
九、为什么同一个操作不能在本地客户端突然变成“需要审批”？
业务动作是否需要审批，应该来自业务能力声明和中枢路由规则，而不是来自客户端自己的猜测。
如果业务系统已经声明：
修改员工普通资料
风险等级：中等
默认不要求审批
那么无论入口是：
- 业务后台里的嵌入式聊天窗口；
- 本地 Agent；
- MCP 客户端；
- 自动化工作流；
它们都应该继承同一套基础治理语义。
客户端不能因为自己运行在本地，就擅自把所有写操作都变成必须审批；同样也不能为了方便，把原本要求审批的操作降级为自动执行。
中枢路由可以根据具体场景进一步收紧，但不能由模型自行放宽。
十、本地编排以后，中枢后台还能看到执行轨迹吗？
应该能看到，但不应该把本地 Agent 的全部思考过程上传到后台。
一条合理的治理轨迹可以记录：
- 这一轮任务何时开始；
- 使用了哪个业务连接和路由；
- 何时完成能力搜索；
- 调用了哪个工具；
- 工具参数包含哪些字段；
- 是否进入审批；
- 工具处于等待、执行、成功还是失败状态；
- 业务系统是否拒绝；
- 任务何时完成；
- 可公开的 Token 用量。
但不应该记录：
- 模型隐藏的思维链；
- 工具参数的原始敏感值；
- 业务接口完整响应正文；
- 浏览器 Cookie；
- Access Token 和 Refresh Token；
- Tool Provider Secret；
- 用户未选择公开的本地文件内容。
企业需要的是可还原的行动证据，而不是把本地 Agent 的所有内部上下文复制到云端。
十一、模型 API Key、BailingHub 授权和业务凭证是三回事
本地 Agent 往往还需要配置一个模型提供方，例如 OpenAI 兼容模型、Anthropic 协议模型或其他自定义服务。
这里至少存在三种不同凭证：
| 凭证 | 用途 | 应由谁持有 |
|---|---|---|
| 模型 API Key | 调用大模型完成本地推理 | 本地 Agent 的安全凭据存储 |
| 中枢连接凭证 | 建立 Agent Client Session | Agent Client SDK 或插件 |
| 业务身份与业务凭证 | 表示当前用户和租户 | 业务系统与中枢授权链 |
三者不能混用。
模型提供方不需要知道用户属于哪个业务租户；业务系统也不应该拿到用户的模型 API Key；本地插件更不应该保存业务系统的超级管理员密码。
十二、现有 SaaS 要接入这种本地 Agent，需要改什么？
至少需要三方配合。
1. BailingHub 部署者
负责配置：
- 中枢地址；
- Client App；
- 工作区和路由；
- 可使用的知识、记忆和工具范围；
- 必要的审批与审计策略。
2. 业务系统开发者
负责提供：
- 基于现有登录状态的授权页面；
- 当前用户、租户和角色的可信绑定；
- 面向 Agent 的业务能力声明；
- 对应业务接口；
- 执行时的最终业务授权。
3. 最终用户
最终用户只需要：
- 安装 Agent Client 或插件；
- 选择自己的中枢连接；
- 在浏览器中登录业务系统并确认授权；
- 在本地 Agent 中发起任务。
最终用户不应该手工填写业务系统数据库地址、管理员密码或内部 API Secret。
十三、第一次验证不要直接从退款和删除开始
对于已经存在的商城、CRM、ERP 或 SaaS，建议先验证“一读一写”。
第一条只读能力
可以选择：
- 查询订单；
- 查询员工；
- 查询客户；
- 查询库存；
- 查询工单。
第一条可回滚写能力
可以选择：
- 修改备注；
- 创建草稿；
- 创建内部工单；
- 更新普通标签；
- 修改非敏感展示字段。
然后至少验证以下情况：
- 未授权客户端不能看到业务工具；
- 错误租户不能访问其他租户数据；
- 用户权限被撤销后，旧 Session 不能继续执行；
- 重复提交不会产生两次写入；
- 超时但结果未知时，只能查询原调用，不能重新创建写操作；
- 中枢后台能够还原工具状态，但不泄露敏感参数和隐藏推理；
- 同一业务动作从嵌入聊天和本地 Agent 发起时，继承相同的基础治理声明。
这七项通过以后，再考虑退款、删除、停用账号、财务提交等高风险动作。
十四、本地 Agent 会取代业务后台里的聊天窗口吗？
不会，它们更可能长期共存。
嵌入式聊天窗口适合：
- 用户正在业务后台工作；
- 任务强依赖当前页面上下文；
- 用户希望边看数据边操作；
- 产品需要提供统一的内置 AI 体验。
本地 Agent 适合：
- 用户希望从桌面统一操作多个系统；
- 任务需要本地文件、代码或操作系统能力；
- 用户希望让 Agent 自主完成多步编排；
- 企业希望选择不同的本地 Agent 宿主。
两者可以复用同一套业务能力、身份体系、知识库、路由和治理中枢，不需要建设两套后台。
十五、BailingHub 在这里扮演什么角色？
BailingHub 的价值不应该被理解为“又一个帮用户调用模型的聊天后端”。
当编排移动到本地以后，中枢反而更需要聚焦在不可被模型随意改写的部分：
- 当前 Agent 代表谁；
- 当前连接属于哪个工作区；
- 哪些能力可以暴露；
- 哪些知识可以进入当前任务；
- 哪些动作必须停下来等待外部决定；
- 如何保证写操作幂等；
- 如何在结果不确定时恢复原调用；
- 如何记录可审计但不过度暴露的执行轨迹；
- 如何让业务系统保留最终授权。
这也是 BailingHub 正在验证的 Agent Client 方向：
本地 Agent 负责思考和编排，BailingHub 负责上下文、治理和审计，业务系统负责最终授权。
本文讨论的是架构方向，不代替具体版本的发布说明。实际安装方式和公开能力边界，应以对应版本的 Release 文档为准。
常见问题
1. 本地 AI Agent 可以直接复用浏览器登录状态吗？
授权页面可以复用浏览器已有登录状态，但本地 Agent 不应该读取或复制浏览器 Cookie。业务系统应通过浏览器授权流程，把当前用户和租户转换为受控的 Agent Session。
2. 安装 MCP Server 后就能操作企业后台吗？
不一定。MCP 解决工具连接和调用问题，但业务身份、租户隔离、审批、幂等、审计和最终授权仍需要独立设计。
3. 业务系统完全不改代码可以接入吗？
如果已有安全的 OAuth、开放 API 和细粒度权限体系，改动可以较小；如果系统连可信身份接口和业务 API 都没有，就需要增加适配层。不存在一种插件可以在业务系统完全不配合的情况下自动创造可信权限。
4. 本地 Agent 能否直接调用业务 API，绕过中枢？
技术上可以，治理上通常不合适。这样会让凭证、能力目录、审批规则和审计分散到每台客户端，并难以保持一致。
5. 一个客户端可以连接多个业务系统吗？
可以，但不同中枢、工作区、租户和业务系统应该形成相互隔离的连接，不能让模型任意拼接 Hub 地址、route 或业务身份。
6. 为什么不把全部知识库同步到本地？
因为知识权限、更新频率和引用范围可能随用户与路由变化。更合理的方式是由中枢按当前任务检索并返回必要的引用或摘要。
7. 审批完成后，本地 Agent 应该重新提交工具吗？
不应该。它应使用原来的调用 ID 恢复同一次调用，否则可能造成重复写入。
8. 执行轨迹会不会泄露模型思维链？
不应该。轨迹应记录工具、状态、治理决定和业务结果边界，而不是上传隐藏推理、敏感参数和完整响应正文。
结语：本地运行解决的是“在哪里思考”，不是“凭什么行动”
把 Agent 放到本地，可以带来更灵活的模型选择、更强的本地工具能力和更自然的多步编排。
但本地运行不会自动产生业务身份，也不会自动获得企业权限。
真正能够进入生产环境的 Agent Client，需要同时解决三件事：
- 本地 Agent 能够自主理解和编排；
- 中枢能够持续提供可信上下文和治理；
- 业务系统始终保留最终授权与拒绝权。
连接只是开始。
当本地 Agent 开始修改员工、创建工单、更新库存或提交业务操作时，系统必须能够回答：
它代表谁？为什么能做？做到了哪一步？发生后如何还原？
这才是本地 Agent 从“能调用工具”走向“能进入真实业务系统”的关键一步。
项目入口：
