夜雨聆风
ClaudeCode 源码风波之后,要不要打造自己的 Agent 平台
这几天，很多人都在讨论 Claude Code。
有的人在讨论那次源码风波本身，有的人在讨论里面暴露出来的产品细节，也有不少人在第一时间开始做各种替代方案：有人去做切换器，有人去做重写版，还有人干脆把它接到本地模型上先跑起来再说。
但我后来越来越觉得，这件事真正值得想清楚的，其实不是“能不能把 Claude Code 用起来”，也不是“能不能快速做一个替代版”。
而是另一个更长期的问题：
如果你自己已经有本地大模型平台，愿意围绕基础设施继续投入，也愿意把 Agent 当成一个长期研究方向，那你到底要不要打造属于自己的 Agent 平台？
这不是一个所有人都要回答的问题。
它对应的是一群很明确的用户：你手里已经有自己的本地模型、推理服务、路由层、模型目录、权限边界和运维方式；你不是只想把一个 AI 工具装来用用，而是愿意围绕这套基础设施继续投入，慢慢把工具执行、会话管理、工作流编排、技能沉淀这些东西接起来。
对这类人来说，ClaudeCode 这次带来的启发，远远不只是“又多了一个好产品可以参考”。
它真正把一个问题摆到了台面上：你的 Agent，究竟是别人的产品接进你的平台，还是你的平台自己长出一层 Agent 能力。
一、这件事之后，社区其实走出了三条路
ClaudeCode 源码泄漏事件，我看到的做法，大致可以分成三类。
第一类：切换派
这条路最典型的代表就是 cc-switch、cc-switch-cli 这一类工具，他们在这件事儿之前就已经很成熟了。
它们解决的问题很直接：Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 这些工具的配置方式都不一样，provider、MCP、skills、proxy、prompt 也各有一套。那不如做一个统一的管理层，把切换、导入、同步、备份、恢复都做掉。
这条路的优点很明显：
-
上手快 -
改动小 -
对多账号、多 provider、多 CLI 工具用户很友好 -
很适合“我就是想把现有工具用顺一点”的人
但它也有一个很清楚的边界：
它的重点是管理和切换，不是平台本身。
更通俗一点说，它帮助你更高效地使用现成的工具，但它并不准备把“你真正打开并开始工作的那一层”拿回来。
这里我想顺手把一个容易说得太玄的词讲清楚。
以前我总会顺口说“前门”。这个词太口语，也容易让人觉得神神叨叨。
更专业一点，可以把它叫作：
- 入口层
- 交互入口层
- Agent 入口
说得再通俗一点，就是：
用户真正打开、发出第一条指令、开始一轮工作流的那一层。
对切换派来说，这一层大多还是别人的。
第二类：重写派
这一类项目里，最有代表性的当然是 claw-code，以及一些 Python 重实现路线。它们的共同点是：不再满足于做配置切换，而是想把 Claude Code 这类产品的结构重新实现一遍，做成一个可以独立运行、可以不断演化的系统。据我了解，claw-code这次重新写，短短4个小时就完成了，我不知道它到底能不能用
这条路的优点也很明显：
-
自由度更大 -
可以把 provider 做成开放的 -
可以摆脱单一厂商语义 -
也更容易形成社区项目
它给人的启发其实不只是“可以重写”，而是另一层意思：
ClaudeCode 这样的产品，值得学习的不是品牌和包装，而是它怎么把会话、工具、命令、权限、上下文、工作流这些东西组织起来。
但重写也有自己的问题。
如果你的目标只是“做一个公开可运行的替代版”，那重写是成立的；可如果你的目标是把 Agent 接到你自己的本地大模型平台里，重写未必就是最短路径。
因为你很容易在不知不觉之间，把注意力从“我自己的平台需要什么”，转移到“我离 Claude Code 完整复刻还有多远”。
而这两件事，其实不是一回事。
第三类：平台派
第三类，就是我最后选择的这条路。
它既不是单纯切换，也不是先重写一遍再说，而是先问自己一个问题：
我到底是想把一个现成 Agent 产品接过来用，还是想让自己的平台慢慢长出 Agent 能力？
如果答案是后者，那很多决策就会变。
你会更关心：
-
模型是不是平台自己的模型目录 -
工具是不是平台自己的执行方式 -
会话是不是平台自己的持久化语义 -
入口层是不是平台自己控制 -
云模型是一个可接入选项，还是唯一真相
这也是 OwlCC 的起点:
它不是为了做一个“Claude Code 换皮版”，也不是为了追求完整替代。
至少现在，它更像是一件非常朴素的事：
先给自己的本地大模型平台，接上一套真正属于自己的 Agent 入口和工作层。
二、为什么我最后没有选前两条路
这件事说白了，不是因为前两条路不对，而是因为它们解决的不是我的核心问题。
1. 我不是在找一个更好的“切换器”
如果目标只是让 ClaudeCode、Codex、Gemini CLI 这些东西切得更顺，cc-switch 这一类产品已经很直接了。
它们做的事情非常实用，也很有价值：统一 provider、统一技能、统一 MCP、统一配置、统一备份。
但我们的问题不是：
“怎么把这些现成工具切换得更顺手？”
我们的问题更像是：
“我已经有自己的本地平台了，我能不能不要总是围着别人的入口层转，而是让 Agent 能力直接长在我的平台上？”
这是两种不同的问题。
切换器会让你更高效地使用别人的工具。
而我们更关心的是，自己的平台以后能不能慢慢拥有自己的交互入口、自己的工作流语义、自己的执行边界。
2. 我们也不是为了“做一个重写版”而重写
重写当然有吸引力。
尤其是当你第一次比较完整地看到一个成熟 Agent 产品的结构之后，很容易产生一种冲动：既然思路已经看到了，那我不如用自己熟悉的语言、自己喜欢的架构，把它再做一遍。
但我们最后没有选这条路，原因也很简单。
我们的目标并不是先做一个“公开可运行的 Claude Code 替代版”，然后再去想它怎么接本地平台。
我们的顺序是反过来的：
先让它成为自己平台的一部分，再决定它以后要长成什么样。
这也是为什么到现在，OwlCC 在我们的定义里，仍然只是第一步。
它目前主要是自用，不会把整套东西直接丢到 GitHub 上。未来如果外围代码整理完整，我们会优先开放外围、开放平台周边、开放和 Agent 相关的执行层与方法层，但这件事的目标，从来都不是把 Claude Code 本体作为一个公开项目再发布一遍。
三、对目标用户来说，真正重要的不是“工具”，而是“平台边界”
我觉得这篇文章最需要写清楚的一点，就是目标用户到底是谁。
不是所有开发者都需要自己的 Agent 平台。
如果你只是想把编码效率提高一点，直接用现成的云产品，或者配合一个切换器，已经足够了。
但有一类人不是这样。
他们通常有几个共同点：
- 已经有自己的本地大模型平台
不管是 Ollama、vLLM、Router，还是更完整的内部模型目录、调度层和控制层，至少基础设施已经不只是“一台机器跑个模型”。
- 愿意围绕基础设施继续投资
他们不会把平台当成一次性实验，而是愿意继续做模型管理、路由、鉴权、日志、执行边界、持久化、目录管理这些“看起来不性感”的东西。
- 把 Agent 当成长期研究方向
他们关心的不只是“写代码能不能更快”，还关心一个 Agent 是怎么组织任务、怎么选择工具、怎么积累技能、怎么和自己的平台深度耦合。
对这类用户来说，真正重要的从来不是“哪一个工具现在最红”，而是：
我有没有自己的平台边界。
这里的平台边界，至少包括四件事：
-
模型边界：模型目录、别名、路由和 availability 由谁定义 -
执行边界：文件、命令、工具调用在谁的规则里运行 -
会话边界：历史、恢复、上下文和持久化由谁掌握 -
入口边界：用户真正开始工作的那一层，由谁控制
如果这四件事长期都在别人手里，那你做得再多，也更像是在“接入一个外部产品”。
如果它们开始慢慢回到自己的平台里，你才算真的进入了另一个阶段。
四、所以真正要讲清楚的，不只是观点，而是这套系统到底怎么运转
如果只讲“要做自己的 Agent 平台”，这件事还是会显得有点虚。
真正重要的是，你至少得把一条最基本的闭环跑通。
对我们来说，这条闭环大致是这样的：
- 用户从入口层发起请求
- 系统先做预检
- 确认模型和路由可用
- 把上游交互协议翻译成本地后端能吃的格式
- 处理流式输出和工具调用
- 在本地执行工具
- 把工具结果再回填给模型
- 把整轮会话落盘，保证下次可以恢复
如果没有这条闭环，你就很难说自己在做一个平台，只能说是在拼接几个点状能力。
1. 第一步不是聊天，而是预检
很多人会先从聊天框开始理解 Agent。
但对本地平台来说，真正的第一步往往不是聊天，而是预检。
也就是在用户真正开始这一轮之前，先确认几件事：
-
路由器在不在线 -
后端模型在不在 -
当前配置是不是可用 -
是否需要复用已有运行实例
如果这一步不做，后面的体验就会非常脆弱：用户只会感觉它时好时坏，不知道问题到底出在模型、路由、配置，还是入口本身。
所以在我们自己的实现里，预检不是一个附属动作，而是入口层的一部分。它决定的是：这次请求能不能成立，以及失败时要把错误归因到哪一层。
2. 第二步是协议翻译，但协议翻译不是简单转 JSON
很多人说“把 Anthropic Messages API 转成 OpenAI Chat Completions 不就行了”。
真做起来你会发现，事情没有这么简单。
难点不在字段映射本身，而在于：
-
文本输出和工具调用会混在一起 -
流式事件有顺序要求 tool_use
和 tool_result之间必须严格成对-
一旦进入多轮工具调用，消息历史就不再只是普通聊天记录
也就是说，协议翻译真正翻译的，不只是格式，还有行为顺序。
3. 第三步一定要有流式状态机
这件事是最容易被低估的。
如果你希望既保留上游那种流式交互体验，又让本地后端和工具执行接得住，你最后几乎一定会走到“状态机”这一步。
在我们自己的实现里，流式过程至少会经过四个基本状态：
- INIT
：消息刚开始，还没确定当前输出到底是纯文本还是工具调用 - TEXT_BLOCK
：当前在连续输出文本 token - TOOL_BLOCK
：当前输出的是工具调用，包括工具名和参数增量 - DONE
：这一轮结束，输出停止原因，准备进入下一轮
这四个状态看起来不复杂，但它解决的是一个很实际的问题：
你不能一边把流式文本往前推，一边又让工具参数乱序插进来。
一旦没有状态机，最容易出的问题就是：
-
文本块没关干净，工具块就开始了 -
多个工具调用之间边界不清 -
参数增量丢失 -
前端显示正常，真实消息历史却是坏的
所以对这类系统来说，状态机不是“高级设计”，而是基本秩序。
4. 第四步不是“支持工具”，而是跑通工具回环
另一个很容易被说轻了的地方，是工具调用。
很多系统会说自己“支持 tool use”。
但如果只是把协议接住，不把工具真正执行起来，那它依然只是一个会说不会做的东西。
真正重要的是把这条回环跑通：
-
模型返回 tool_use -
本地运行时根据规则决定是否执行 -
如果涉及文件或命令，要经过边界判断和批准逻辑 -
生成 tool_result -
再把 tool_result回填给模型 -
模型继续完成这一轮
对本地平台来说，这里最关键的其实不是“工具多不多”，而是两件事：
- 边界清不清楚
- 规则是不是自己定义
比如什么算工作区内，什么算工作区外；什么命令要批准，什么文件操作必须警告；这些东西如果不在自己手里，平台就永远只是借壳运行。
5. 第五步必须把会话当真
最后一个很容易被忽略的，是会话。
如果只是临时对话，那一切都很轻松。
但一旦你想把 Agent 真正接到自己的平台里，会话就必须变成一个可恢复、可追踪、可持续的东西。
这意味着至少要做几件事：
-
每轮消息落盘 -
记录当前模型 -
保存用户、助手、工具调用、工具结果这些完整轨迹 -
支持恢复 -
恢复以后还能延续原来的语义，而不是重新开一局
这时候，会话不再只是“聊天记录”，而是平台的一部分运行真相。
五、OwlCC 到现在做的，其实只是把这条闭环先走通了第一段
所以我不太想把 OwlCC 写成一个“我们做成了什么”的故事。
更准确一点，它现在只是把这个方向先走通了第一段。
这第一段，大致做了几件事。
第一件事：先把本地平台接住
最早要解决的不是体验，而是兼容和落地。
如果一套东西默认围绕云端产品设计，你就得先把本地平台能够承接的那些地方补起来：接口、配置、启动路径、模型显示、登录语义、环境注入、运行边界。
这一步做完，你得到的还不是一个成熟平台，但至少不再只是“把请求转发一下”。
第二件事：把入口层拿回来
这是后面越来越清楚的一件事。
只要默认交互入口还掌握在外部工具手里，你就很难说自己真的有了平台级能力。
所以对我们来说，后面的重点逐渐变成：
-
入口层归自己 -
模型面归自己 -
会话语义归自己 -
工具执行归自己
这并不意味着不要借鉴 Claude Code。
恰恰相反，我们非常承认 Claude Code 是一个很好的产品起点。问题不在于“要不要参考它”，问题在于：
参考它之后，你是继续围着它工作，还是借它长出自己的东西。
第三件事：先服务自用，再谈开放
到今天，OwlCC 仍然主要服务自用。
这个判断不是保守，而是因为这件事如果真要往长期走，最重要的不是先把名字打出去，而是先把几件基础工作慢慢压稳：
-
本地模型平台接入 -
本地与云端的切换 -
工具执行的边界 -
会话恢复与工作流连续性 -
技能与方法的沉淀方式
它们现在并没有终局。
但至少，我们已经知道该往哪条路上继续走。
六、所以这件事最后留下来的，不只是一个项目，而是一种做法
如果只从热点角度看，Claude Code 这次风波最容易被记住的，是讨论、流量、镜像、重写和各种替代方案。
但如果从更长一点的时间尺度看，我觉得更值得留下来的，是另一个判断。
那就是：
当一个 Agent 产品足够好时，它带给行业最深的影响，未必是大家都去复制它，而是迫使更多人开始认真思考：自己到底要不要有一套属于自己的 Agent 平台。
这件事对普通用户可能不重要。
但对那些已经有本地大模型平台、愿意围绕基础设施继续投入、也愿意把 Agent 当成长期研究方向的人来说，它会越来越重要。
因为你迟早会走到那个问题面前：
你到底是在“接入别人的 Agent”，还是在“让自己的平台长出 Agent 能力”。
对我来说，OwlCC 现在只是这个问题的第一个回答。
它不是终点，也不是成品。
它只是让我更确定了一件事：
未来真正值得投入的，不只是某一个工具，而是围绕自己的平台，慢慢把入口层、执行层、会话层和工作流层都长出来。
而这，大概也是 Claude Code 这件事过去之后，最值得想清楚的地方。