住在你电脑里的
数字生命

这是 agent 的通病：工具越加越多，提示词越堆越肥，结果学得越多反而越迟钝、越烧钱。

OneKey 的做法是把一段活先拆成阶段，每个阶段标明是哪一科——前端实现、后端实现、数据处理、数据分析、调研写作、文档产出、自动化运维，或者通用。 一进入某个阶段，系统就按这一科，把最对口的几篇心法和几个工具递到手边；进入下一阶段，换一批，上一批用完即卸。

关键在于这份「能力菜单」是随任务通知递进来的，不常驻系统提示词：它跟着阶段走，随对话往后滚，不会一直压在上下文最前面。 五十多个内置工具全程注册在位、随时可调，但默认只有核心几个把接口说明摆进上下文，其余的先给一份简目， 模型要用哪个再现场装载。心法也一样——真要套用某篇方法论时，它会开一个隔离的分身把这篇心法整个挂上去跑，跑完即弃，不污染主对话。

«越用越强» 这四个字，在 OneKey 这里有四条具体的路径，而且其中两条是不需要你下命令的。

把 agent 塞进某个 IM，最后总会变成一堆写死的适配代码：这里拼个字符串，那里贴张图，换个平台推倒重来。 更麻烦的是这些代码和主程序长在一起——哪个平台的库抽了风，整个人跟着躺下。

所以在 OneKey 里，每个渠道都是一个跑在独立子进程里的插件。写插件的人只实现三个方法：接上、断开、发一条消息。 他不能直接 import 内核里的任何东西，只有一个入口——一个承诺大版本内向后兼容的 SDK。 想把收到的消息投进推理、想跨渠道推送、想写日志、想发 HTTP、想存点东西，全部经这个入口过一道； 其中发 HTTP 还得先在自己的清单里报备域名，没报备的地址根本走不出去。

主进程这头盯着它们活得怎么样：起不来有就绪超时，崩了按指数退避重启，六十秒内崩满三次就熔断—— 不再空转重启，并从别的还通着的渠道给你发一条告警。

正因为插件的边界这么窄，接一个新软件才轮得到它自己动手。 它有一套渠道开发工具：生成骨架、写代码、装依赖、先在一个隔离的临时子进程里连通性自测， 过了才来请你审批；你批准之后才金丝雀上线——起一个新进程，就绪成功才切流量过去， 起不来就把新的杀掉，老的继续跑，你这边一点感觉都没有。随时可以回滚到上一份备份。

目前接了微信、飞书和门户直连——飞书那套适配器，是它自己写出来的，代码躺在外挂目录里， 旁边还留着几份历次上线的备份。

内核里只产出一种东西：一个结构化信封——标着意图（进度 / 结果 / 提问 / 主动招呼 / 告警），装着一串内容块（文本、图片、文件、视频、卡片、进度条），带上来源。 内核从头到尾只面对这一种东西，它不知道微信长什么样。

落地的活交给每个渠道各自的出口，由它声明这个平台实际能发什么：能不能带图、能不能传文件、能不能编辑已经发出去的消息。 说清楚一点——适配的方向从来都是我们去迁就平台，微信不会为谁改规矩。这套结构省下的不是这份适配工作， 而是把它收进了一个固定的接口：翻译规则住在各自的出口里，平台的脾气全挡在那一层，往上走的内核一行都不用动。

发之前，每个出口按自己声明的能力把信封翻译一遍：发得走的附件就带走，发不走的在正文里留一句「[file: 周报.xlsx]」，绝不静默丢东西。卡片、进度条、消息改写这类富交互目前一律降级成文字段落——能力位留好了， 但还没有哪个渠道真的走原生渲染。同一句话到了不同软件里，长相不同，信息不掉。

出站还有一层路由：你从哪个渠道叫的它，回执就回哪个渠道；没指定就按「你最近人在哪」挑一条通得过去的路。 显式指定的渠道如果不通，它宁可报错也不偷偷换一条路发给你。