OpenClaw 最近很火，又带动了一波 AI Agent 框架的讨论。
我们团队开源了一个类似定位的项目 OpenPollen（github.com/tom-byte-sys/OpenPollen），也是做 AI Agent 框架的，但技术路线和 OpenClaw 完全不同。
今天不是来打擂台的，而是想聊聊我们在做这件事的过程中，思考过的一个核心问题：
AI Agent 框架的引擎层，应该自己造还是站在别人肩膀上？
自己造引擎的尴尬
2024 年底，我们团队开始做内部的 AI Agent 系统。第一版的方案很自然——自己写引擎：自己管理上下文、自己实现工具调用、自己做任务编排。
写了两个月，确实能跑了。
然后 Claude 3.5 升级到 Claude 4，模型的工具调用格式变了，我们的引擎适配了一周。
再然后 GPT 出了个新的 function calling 协议，又改了一周。
再再然后，我们想支持国产模型，发现每家的工具调用协议都不太一样——有的用 JSON Schema，有的用自己的格式，有的干脆不太稳定。每接一个模型，引擎层就要改一遍。
更要命的是：我们花了大量精力在上下文管理上，效果还是不好。
长对话 token 爆了怎么压缩？多轮工具调用的中间结果要不要保留？文件内容什么时候该塞进去、什么时候该省掉？这些问题每一个都有无数种处理方式，每一种都影响最终效果。
我们做了很多实验，效果一直在「能用」和「好用」之间摇摆。
一个让我们转变思路的发现
转折点是一次偶然的对比测试。
我们拿同一个 GLM-4 模型，分别接入我们自己的引擎和 Claude Agent SDK（Claude Code 背后的编排引擎），跑同一组任务。
结果差距明显。
同一个模型，在我们引擎里只能完成 60-70% 的复杂任务，接入 Claude Agent SDK 后能到 85-90%。
模型没变，引擎变了，效果就变了。
这让我们开始认真看 Claude Code 团队在引擎层做了什么：
- 上下文窗口管理：他们有一套非常精细的策略来决定什么内容留在上下文、什么压缩、什么丢弃。不是简单地截断，而是根据任务相关性做智能筛选。
- 工具调用编排：什么时候该并行调用多个工具、什么时候该串行、什么时候该把工具结果摘要后再喂回去——这些策略直接决定了 token 消耗和任务完成率。
- token 控制：这是 Claude Code 用户可能感知不到但极其关键的能力。同样的任务，好的引擎可能用 2 万 token 完成，差的引擎要用 8 万 token，而且效果还不如前者。
这些东西，不是你花两个月就能做到同等水平的。Claude Code 团队在这上面的工程积累，是以年为单位的。
所以我们换了条路
我们做了一个看起来有点"偷懒"但实际上很务实的决定：
不造引擎，用 Claude Agent SDK。把精力全部放在引擎之上的事情上。
这个决定带来了三个直接的好处：
1. Token 不浪费
Claude Agent SDK 的上下文管理是经过 Claude Code 数百万用户验证的。它知道什么时候该压缩历史消息，什么时候该保留关键信息，什么时候该把文件内容摘要化。
我们之前自己写的引擎，经常出现这种情况：一个简单的代码审查任务，由于上下文管理不当，token 消耗是合理值的 3-4 倍。用了 SDK 之后，这类问题基本消失了。
对用户来说，同样的月费额度，能干更多事。对我们来说，不用在上下文管理这个无底洞里反复调参。
2. 大模型升级不怕
这一点可能是最被低估的优势。
如果你自己造引擎，每次大模型厂商升级 API 协议、改变工具调用格式、调整上下文窗口大小，你都得跟着改。GPT 改一次，Claude 改一次，国产模型各改一次。
用 SDK 就不存在这个问题。Claude Code 团队会替你做适配。 他们更新一个版本，你 npm update 一下，新的模型能力、新的优化策略，自动就有了。
最近的例子：Claude Code 新出了**智能体团队（multi-agent）**能力，可以让多个 Agent 协作完成复杂任务。如果是自己造引擎，这种特性从设计到实现要几个月。我们呢？SDK 升级，直接可用。
3. 不会做了一堆无用功
做底层引擎最大的风险不是"做不好"，而是"做好了也白做"。
大模型发展太快了。你今天精心调优的 prompt 模板，可能下个月模型升级后反而变差。你今天设计的上下文压缩算法，可能下个版本模型原生就支持了更大的窗口。
越底层的东西，被模型升级颠覆的风险越大。
相反，渠道接入、企业集成、技能系统这些业务层的东西，不会因为模型升级就失效。钉钉的 SDK 不会因为 GPT-5 出了就改掉，企业微信的消息格式也不会因为 Claude 升级就变化。
把精力花在不会被颠覆的事情上，才是理性的选择。
我们把省出来的精力做了什么
不造引擎之后，我们把所有精力放在了国内企业真正缺的东西上：
九个渠道的原生接入。
| 渠道 | 状态 |
|---|---|
| 钉钉 | ✅ Stream API 长连接 |
| 企业微信 | ✅ 官方 SDK |
| 飞书 | ✅ 官方 SDK |
| ✅ 官方开放平台 | |
| Telegram | ✅ Bot API |
| Slack | ✅ Socket Mode |
| Discord | ✅ Discord.js |
| ✅ IMAP/SMTP | |
| WebChat | ✅ 内置 Web UI |
这才是真正的脏活累活——每个平台的 SDK 都不一样，消息格式都不一样，认证方式都不一样，异常处理都不一样。一个一个啃下来的。
还有国产模型的全面支持。Claude、Kimi、GLM、千问、DeepSeek、Ollama 本地模型，全部接入。而且所有模型都走 Claude Agent SDK 的编排引擎——前面说了，好的引擎能让中等模型发挥出更好的效果。
以及 SKILL.md 技能系统——用一个 Markdown 文件定义一个 Agent 技能，不需要写代码：
---
name: code-review
description: 代码审查
allowed-tools: Read, Grep, Glob
---
你是一个资深代码审查专家。
检查安全漏洞、性能问题和代码规范，按严重程度排序输出。
会写 Markdown 就会写技能。
和 OpenClaw 的路线差异
不踩 OpenClaw，每个项目有自己的技术判断。但路线确实不同：
OpenClaw 的路线：自建引擎，深度控制每一层。优点是灵活度高、不依赖第三方；代价是工程量大，引擎层的优化需要持续投入。
OpenPollen 的路线：引擎层用 Claude Agent SDK，在上层做差异化。优点是引擎免费享受 Claude Code 团队的持续优化，精力集中在业务层；代价是和 SDK 有耦合，受限于 SDK 的能力边界。
两条路线没有对错，取决于你怎么判断：
- 如果你相信引擎层的差异化才是 Agent 框架的核心壁垒——选 OpenClaw 的路线。
- 如果你相信渠道接入、企业集成、生态适配才是真正的刚需，而引擎层会趋于标准化——OpenPollen 的路线更务实。
我们选后者。
三条命令跑起来
npm install -g openpollen
openpollen init
openpollen start
打开 http://localhost:3001，在内置的 WebChat 里直接对话。如果要接钉钉、企业微信、飞书，openpollen init 的向导会引导你配置。
完全自托管，数据不出你的服务器。配合 Ollama 本地模型，可以做到完全离线运行。Apache 2.0 协议，随便用。
GitHub：github.com/tom-byte-sys/OpenPollen
标签：OpenClaw、OpenPollen、AI Agent、Claude Code、Claude Agent SDK、智能体框架、开源、钉钉、企业微信、飞书
