9月2日，WorkBuddy 开放平台开始公开提供 Buddy 应用、专家、Skill、连接器和硬件五类生态入口。
这件事值得关注的地方，不只是"又多了一个插件市场"。
它意味着桌面 Agent 正在从一个由平台自己提供能力的产品，变成一个可以持续接入外部工具、专业知识、行业流程和业务系统的生态入口。
按照 WorkBuddy 官方文档，开发者可以通过连接器把第三方服务带进 Agent：已有 API 服务可以使用 MCP + Skill，已有成熟命令行工具也可以采用 CLI + Skill。更上层的 Buddy 应用，则可以把工作模式、场景胶囊、模型、专家、Skill 和连接器组合成一个面向特定行业的 AI 工作台。
这套分层很有想象空间。
未来我们很可能会看到越来越多连接器：文档、邮件、项目管理、客户数据、商城、CRM、ERP、工单、库存、财务软件，都可能成为 Agent 可以使用的外部能力。
但连接器数量增加，并不意味着 Agent 已经可以安全地进入真实业务系统。
真正困难的问题，往往发生在"已经连上"之后。
从"能调用工具"到"能办理业务"，中间还有一层
连接器最直观的价值，是让 Agent 知道某种工具存在，并能够按照约定格式发起调用。
例如用户在 WorkBuddy 中说：
帮我找出库存低于 10 件的商品。
连接器找到商品查询工具，传入条件，返回结果。这条链路相对容易理解。
但如果用户接着说：
按照最近 30 天销量生成补货单，把已经停售的商品下架，再通知采购负责人。
问题马上变了。
这已经不只是数据读取，而是可能产生真实业务后果的操作：
- 这句话是谁说的？
- 他代表哪家公司、哪个租户或哪家门店？
- 他能查询哪些商品？
- 他是否有权创建采购单？
- 商品下架是否需要二次确认或审批？
- Agent 生成的参数和批准时看到的参数是否一致？
- 接口超时后到底成功了还是失败了？
- 如果 Agent 重试，会不会重复创建采购单？
- 最后是谁、通过哪个 Agent、调用了什么能力、改了哪些数据？
连接器可以解决"怎样调用"，却无法单独回答全部这些问题。
这就是普通工具连接和生产级业务接入之间的差别。
WorkBuddy 的开放，真正打开了哪扇门？
WorkBuddy 开放平台目前把生态能力分成 Buddy 应用、专家、Skill、连接器和硬件。这些资产承担的角色并不相同。
Skill 和专家：告诉 Agent 怎样完成一类任务
它们更接近方法、知识和流程编排。一个财务专家可以知道怎样分析报表，一个运营 Skill 可以规定商品诊断的步骤。
连接器：让 Agent 获得外部能力
连接器把第三方服务、API 或 CLI 带入 WorkBuddy，让 Agent 不再局限于回答文字，而是能够读取数据、调用工具并推动任务执行。
Buddy 应用：把能力组织成完整场景
Buddy 应用并不是连接器的另一个名字。它是更上层的行业 Harness，可以组合工作模式、场景入口、模型、专家、Skill 和连接器，让用户打开后直接进入某个行业工作台。
比如一个"商城经营助手"可以预置库存分析、商品运营和售后处理场景，并关联对应连接器；一个"客户成功助手"可以组织 CRM 查询、续费提醒和工单处理能力。
因此，WorkBuddy 解决的是非常重要的一层：
Agent 从哪里运行，用户从哪里发起任务，能力怎样被发现、安装和组织。
但当连接目标是开发者自己的商城、SaaS、CRM 或 ERP 时，还需要回答另一组问题：这些系统怎样在不交出管理员密钥、不绕过原有权限的前提下，把真实业务能力交给 Agent。
业务系统和普通工具，最大的不同是什么？
连接一个天气查询、公开搜索或格式转换工具，主要关注参数是否正确、结果是否可用。
连接订单、库存、退款、员工和客户系统，则会触及三种更重的边界。
第一种：身份边界
"查询订单"不能只看用户输入了哪个订单号，还必须知道当前代表哪个真实业务用户、属于哪个租户、能够访问哪些门店。
模型输出的 user_id、tenant_id 或 store_id 不能直接成为可信身份。可信主体应该来自业务系统已经完成鉴权的登录状态或授权流程。
第二种：动作边界
同一个系统里的能力风险并不相同：
- 查询商品是只读动作；
- 修改商品标题是普通写操作；
- 批量下架可能影响经营；
- 退款、转账和删除数据可能需要审批；
- 某些动作即使审批通过，执行前仍要重新检查订单状态和用户权限。
把整套后台包装成一个通用 CRUD 工具，并把管理员 Token 交给 Agent，接入会很快，风险也会一起被放大。
第三种：责任边界
如果工具可能已经执行成功，但本地网络断开或审计写入失败，Agent 能不能直接重试？
对于查询，重试通常问题不大；对于退款、采购和库存调整，盲目重试可能制造第二次业务后果。
生产级连接器不仅要返回"成功"或"失败"，还要提供稳定请求标识、幂等语义、可查询结果和足够的执行轨迹。
一个能进入生产的业务连接器，至少要回答七个问题
未来连接器市场真正拉开差距的，可能不是"提供了多少工具"，而是能不能稳定回答下面七个问题。
1. 当前代表谁？
连接器是否建立了真实、可撤销的业务身份，而不是让模型自行填写用户和租户字段？
2. 能看到哪些能力？
Agent 获得的是整个后台，还是只获得当前客户端、Workspace、角色和业务身份允许使用的一小组动作？
3. 哪些动作可以直接执行？
只读、普通写入、高风险写入是否被区分？连接器有没有把"模型选择了工具"误当成"业务已经授权"？
4. 哪些动作需要确认或审批？
审批是否绑定了参数快照、有效期和具体业务对象？批准以后，执行前是否还会重新校验实时权限和业务状态？
5. 重试会不会制造第二次业务后果？
是否存在稳定的 request_id、幂等处理和未知终态核账机制？接口超时后能否先查询事实，再决定是否重试？
6. 发生了什么，能不能追溯？
系统能否说明哪个用户、哪个 Agent、从哪个入口、调用了哪个工具、使用了哪些参数、最后得到什么结果？
7. 谁拥有最终决定权？
无论 Agent 平台和控制面如何判断，业务系统是否仍会根据真实角色、数据归属和当前状态完成最终校验？
如果这七个问题没有答案，连接器可能适合演示，但很难放心地交给真实员工长期使用。
WorkBuddy、连接器、BailingHub 和 ACC 应该怎样分工？
这几层不是互相替代的产品，而是可以组合的职责。
text
业务用户
↓
WorkBuddy / Buddy 应用
↓
WorkBuddy 连接器
↓
BailingHub 治理控制面
↓
现有商城、SaaS、CRM、ERPWorkBuddy：Agent 运行与生态入口
WorkBuddy 提供面向用户的智能体环境、工具编排以及专家、Skill、连接器和 Buddy 应用等生态入口。用户在这里描述目标，Agent 在这里完成规划并调用能力。
其官方文档也把安全与权限管控列为平台基础能力。这里需要区分的不是"平台有没有安全"，而是两层权限不能互相替代：Agent 平台负责自己的用户、连接和能力使用边界；商城、SaaS、CRM 等业务系统仍要负责本系统内部的租户、角色、数据归属和最终业务授权。
WorkBuddy 连接器：把治理后的能力交给本地 Agent
连接器负责安装、认证、状态检查和调用适配，让 WorkBuddy 能够发现并使用外部能力。它是独立的生态适配器，不应该把某个业务系统的管理员凭据打进安装包。
BailingHub：连接 Agent 与现有业务系统的开源控制面
BailingHub 的作用不是取代商城、CRM 或 ERP，也不会凭空拥有开发者的业务数据。
开发者需要先在自己的系统中声明可以开放给 Agent 的业务能力。BailingHub 再负责按接入方和业务身份投影能力，处理策略、审批、调用与审计，并把受治理的工具交给 WorkBuddy 等 Agent 使用。
ACC：实现中立的能力治理契约
ACC（Agent Capability Contract）不是 WorkBuddy 的插件格式，也不是另一个连接器市场。
它尝试用实现中立、机器可读的方式描述一项业务能力的身份边界、作用范围、风险、审批要求和审计元数据，让不同 Agent、控制面和业务系统能够对"这是什么动作、在什么条件下可以执行"形成一致理解。
ACC 不负责业务登录，也不替代业务系统的最终授权；BailingHub 是 ACC 思想的一种开源工程实现。
业务系统：最终 Authority
订单是否属于当前门店、员工是否可以修改、退款是否满足状态条件，最终仍应由业务系统判断。
Agent 平台负责规划，连接器负责连接，控制面负责治理，但真实业务系统不能失去最后一道权限边界。
为什么这对 WorkBuddy 生态很重要？
生态开放的第一阶段，大家通常会关注数量：有多少 Skill、多少专家、多少连接器，可以调用多少工具。
第二阶段，用户会开始关注效果：这些能力能否组合成真正好用的场景，是否能减少重复工作。
到了第三阶段，企业会追问信任：
- 能否沿用现有账号和组织关系？
- 能否限制不同部门和门店看到的能力？
- 写操作是否可以审批？
- 能否撤销某台设备或某个 Agent 的授权？
- 出现问题后能否找到完整轨迹？
- 是否需要为了接入 Agent 推倒重做原有系统？
连接器让外部能力进入 Agent，是生态扩张的起点；身份、权限、审批和审计，决定这些能力能不能留在生产环境中。
真正优质的业务连接器，最终不会只展示"我们有 100 个工具"，而会清楚告诉用户：
当前代表谁，可以做什么，哪些动作需要确认，业务系统为什么最终允许，以及发生问题后怎样追溯和撤销。
对商城、SaaS 和 CRM 开发者，应该从哪里开始？
如果你希望自己的系统进入 WorkBuddy 或其他 Agent 生态，不建议第一步就把全部 OpenAPI 包装成 MCP 工具。
可以先选择一个最小闭环：
text
一套业务系统
+ 一个真实测试身份
+ 一条高频、低风险动作
+ 一份脱敏接口说明例如：
- 查询一条测试订单，并创建内部跟进工单；
- 找出低库存商品，并生成待确认的补货建议；
- 查询一个客户，并更新一项允许修改的普通资料；
- 读取门店经营数据，并生成不直接写库的分析结果。
然后验证完整链路：
- Agent 能发现正确能力；
- 身份来自真实业务授权；
- 无权限身份会被最终拒绝；
- 低风险写操作可以完成；
- 重复请求不会重复产生业务后果；
- 中枢和业务系统能够对上同一次执行轨迹；
- 用户撤销授权后不能继续调用。
跑通这一条真实动作，比一次性暴露几百个 API 更能说明系统是否具备进入 Agent 生态的条件。
BailingHub 为什么正在接入 WorkBuddy？
BailingHub 希望验证的不是"能不能再做一个聊天入口"，而是：本地 Agent 能否在获得真实业务身份后，直接发现并调用开发者已经开放的业务能力，同时把策略、审批和审计继续留在治理控制面中。
目前，独立的 BailingHub WorkBuddy 连接器 0.1.1 已经完成公开代码、npm 包和跨平台验证，并已提交 WorkBuddy 审核；当前仍然只是审核中，尚未形成 WorkBuddy 市场公开入口。
这不代表 WorkBuddy 官方认证、推荐、合作，也不代表已经出现外部采用。Buddy 应用目前也没有创建或提交。
但这次接入让我们更确定一件事：
当 Agent 平台开始开放连接器生态，BailingHub 这类业务动作治理控制面，以及 ACC 这类实现中立契约，会有一个更具体的落点。
它们不是用来和 Agent 平台争夺用户入口，而是帮助不同 Agent 平台安全进入原本就存在的商城、SaaS、CRM 和 ERP。
最后：下一阶段的竞争，不只是"连接了多少 API"
WorkBuddy 开放生态，会让更多开发者有机会把自己的能力带进桌面 Agent，也会推动专家、Skill、连接器和行业应用形成更多组合。
但对于真实业务系统，数量只是第一层指标。
更重要的问题是：
- Agent 能否代表一个真实、可撤销的业务身份；
- 能否只看到当前允许使用的能力；
- 能否在写入前完成必要确认或审批；
- 能否处理重试、幂等和未知终态；
- 能否让每一次真实业务后果都可以追溯；
- 能否始终保留业务系统的最终决定权。
连接器解决"接进来"，Buddy 应用解决"怎么用"，治理层解决"凭什么做"，业务系统决定"最终能不能做"。
当这几层真正组合起来，Agent 才不只是多了一个工具列表，而是开始在清晰的身份和责任边界内办理真实业务。
延伸阅读与行动入口
- WorkBuddy 开放平台
- WorkBuddy 连接器文档
- WorkBuddy Buddy 应用文档
- BailingHub 开源仓库
- BailingHub WorkBuddy 连接器
v0.1.1 - 如果你已经有"一套业务系统 + 一个真实身份 + 一条动作 + 一份脱敏接口"，可以通过接入评估 Issue验证第一条受治理业务动作。
事实边界：WorkBuddy 的五类生态能力、连接器接入方式与 Buddy 应用定位来自其当前官方公开文档；本文对生态阶段和生产级业务连接器的判断属于作者观点。BailingHub WorkBuddy 连接器当前仍处于审核中，不能表述为已经上架、平台认证、推荐、合作、独立验证或采用。