跬步 On Coding

复盘：ClawOps AI Agent

Mar 7 2026

前言

过去的两周，我经历了一次充满激情的开发，也经历了一次彻底的失败。

起因是我准备在内部做一个公共的“运维AI机器人”。我满怀热情地规划了多租户架构、复杂的并发控制、MCP（Model Context Protocol）对接以及各种内部系统的打通。然而，经过两周的爆肝，项目上线没多久就被平台团队勒令下线，而从业务价值来看，老板其实也并不需要这样一个东西。

俗话说，失败是成功之母。虽然项目黄了，但这两周踩过的坑、写过的废代码，都是技术架构演进路上的宝贵经验。我在这里复盘一下整个过程，聊聊我的技术实现、妥协，以及如果让我重新设计，我会怎么做。

1. 雄心勃勃的初始架构

项目初期的定位非常庞大：一个服务于全公司的公共运维Agent平台。为了支撑这个目标，我设计了一套相当复杂的服务端架构。

项目本身基于 PicoClaw。

在这个阶段，我的思维主要停留在“如何用技术解决所有场景的问题”。

  • 多租户与隔离：每个用户拥有独立的Workspace，利用文件系统工具和Shell工具的黑名单机制进行隔离。
  • 高并发的AgentLoop池：为了支持多用户，我设计了一个AgentLoop Worker池。当Inbound Bus收到消息时，自动分配Worker处理；处理完毕后通过Outbound消息池并发调用Channel的发送接口，随后Worker自动回收。
  • Web Channel的设计：为了让用户能在网页上使用，我做了一个Web Channel。前端通过POST接口发送消息到Inbound Bus，服务端通过SSE（Server-Sent Events）向前端持续推送AI的回复。同时，Tool调用的过程也会产生摘要，通过Hook机制经SSE推送给前端，连会话的Title都是AI自动生成并推送的。
  • 状态与存储：Web会话和消息数据全部落盘MySQL。因为是公共服务，Inbound进入前和Outbound发出后，都需要对接内部认证组件拦截并识别用户，将用户信息注入Message Metadata，最终融合到LLM的System Prompt中。
  • 内部IM（WPS协作）集成：通过WebSocket连接获取内部IM机器人的消息，提取出内部用户信息注入Inbound，再通过平台的发消息API回传给用户。由于共享Metadata，WPS端和Web端可以共用同一个AgentLoop实例和Workspace记忆。

初期架构流转图大概是这样的：

Image3

除此之外，我还实现了一个多用户的Cron任务管理服务。系统会遍历每个用户的Workspace，拉起Cron实例。AgentLoop中会记录用户的 last channel，以此决定定时任务的执行结果该推送到Web还是WPS（由于Web没有主动推送能力，还需要做特殊处理屏蔽Web Channel记录）。

2. 核心能力建设与“妥协”

在Agent本体骨架搭好后，下一步就是Skill（技能）的建设。这里我遇到了几个典型的架构决策问题。

WPS 365 MCP的对接与Proxy模式

我们内部使用了WPS 365，它提供了MCP。但是它的MCP使用OAuth2协议，AccessToken只有2小时有效期。 如何让AI顺畅调用？我最初的想法是写个Wrapper程序直连数据库刷新Token，但这太不优雅了。最终的妥协方案是：在Web服务上暴露一个WPS MCP Proxy。

调用这个Proxy时携带User ID，Proxy负责去数据库换Token、组装认证请求头，最后转发给WPS。这样一来，AI只需要用普通的 mcptools 配合用户ID就能完成调用。

CMDB对接：CLI vs MCP

在对接内部CMDB平台时，我有了一个洞察：其实MCP并没有那么神圣，面向Agent开发的CLI工具才是未来。因为Agent的Shell Tool结合Skill可以搞定一切CLI的调用，而且极为灵活。

于是我把内部服务直接包成了一个CLI工具给Agent调用，并写了Skill说明文档。但Leader认为，这种能力应该包装成标准的MCP提供给其他生态。

这是一个典型的业务视角与开发视角的冲突。没问题，我把它改成了MCP暴露，但紧接着认证又成了痛点——现阶段做AI工具调用，搞复杂的统一认证太累了，其实最简单的固定Token透传才是效能最高的。

3. 失败的根因与挣扎

项目开发完了，写好了帮助文档，准备大干一场。然后，就迎来了平台团队的审核。

下线。

复盘这个结果，核心死穴在于：Sandbox（沙盒）隔离方案太简陋。

我原本以为，在程序层面做一个Shell命令的黑名单（比如禁用 rm、ssh）就万事大吉了。但我忽略了平台本身网络环境的复杂性。内部平台机器之间的网络是没有严格隔离的。Agent最核心的能力是能够自主编写Skill扩展能力、执行脚本。这意味着无论我怎么在应用层做黑名单，只要Agent能执行Python/Shell，它就能在内网里横冲直撞。要想解决，必须依赖底层平台做深度的容器网络隔离，而这在短时间内根本推不动。

服务端走不通，我不甘心，于是决定转向客户端（桌面版）。

我用Golang的 Wails 框架，花了极短的时间糊了一个和网页端一样的桌面客户端。

  • Wails甚至能直接Hook之前写的Gin路由。
  • 因为不支持SSE，我把推送机制改造成了Wails自带的Event Bus。
  • MySQL太重？直接切成SQLite本地存储。
  • WPS协作只能单实例WebSocket连接？我在服务端保留了一个非常轻量的“消息转发网关”，根据User ID把消息路由到对应打开的客户端上。

技术上走通了，但这次碰到了最终的BOSS——业务价值伪需求。 从老板的角度来看，团队并不需要一个新的、复杂的公共Agent平台。能力强的同事早就自己部署了类似的开源项目（比如OpenClaw），而能力稍弱的同事用Cursor就能解决80%的代码和运维问题。

4. 复盘：如果重来，我会怎么设计？

在之前的文章中我提到过，解决问题有不同的思维层次。

我这次的失败，在于我用第一层（用技术解决看到的所有问题）的精力，去挑战了第四层（从组织与平台底座出发看演进）的难题，最终因为基础设施不匹配和伪需求而夭折。

如果让我重新规划这个项目，我绝对不会立项做一个“多租户的企业级公共Agent”。我会将其彻底定位为一个极致轻量化的“个人AI助手（Personal AI Agent）”。

以下是我的重构思路：

1. 抛弃统一认证，拥抱本地配置（Identity）

既然是个人助手，就不要去对接什么内部复杂的SSO认证了。用户的身份定义完全下放。

用户只需要在本地修改自己的 USER.md 文件，明确自己的职责、系统偏好等。对于CMDB这种系统，直接在本地配置里写入私人Token，LLM在调用CLI或MCP时自动拼装读取即可。

2. WPS 365 MCP 授权的本地化改造

不需要服务端的Proxy和数据库。我会开发一个专用的CLI工具。

用户在本地执行CLI生成认证链接，浏览器授权后将Callback的AccessToken及其Refresh Token直接存入本地配置目录（如 ~/.wps/config.json）。之后的Token刷新完全由本地CLI自动完成，Agent直接调用本地工具即可。

3. 极简的Channel消息路由

保留服务端的“消息路由网关”，但不做任何用户认证。

WPS机器人在收到消息后，直接告诉用户他当前的 Chat ID。用户只需在自己本地助手的配置里填入这个 Chat ID。本地助手连上服务端网关的WebSocket，网关只负责无脑地按 Chat ID 转发消息。安全、轻量、解耦。

新的架构图将变得异常清晰且易于维护：

Image3

5. 结语

软件开发的过程，本质上是对业务需求进行抽象、提炼并构建逻辑的过程。

这次历时两周的“失败”，虽然没有产出能在公司内部大放异彩的平台产品，但它逼着我理清了Agent在ToB复杂网络下的安全死结，也帮我认清了“大而全的平台”与“小而美的个人工具”之间的边界。

做技术不能一味地追求架构的宏大（什么都想上多租户、Worker池、分布式），最终还是要服务于真实的痛点。现在的个人版架构，虽然看起来像是一个妥协的产物，但它没有了沉重的安全包袱，没有了复杂的数据库依赖，反而能把Agent的核心能力（工具调用、记忆、任务流）发挥到极致。

有时，砍掉一半的需求，反而能得到一个更健壮的架构。这就是我这两周交出的学费。