做 Agent 框架以来的这一年

从做 trpc-agent-go 项目以来差不多一年多了，我感觉心中有很多想法，但是表达的没有那么彻底和足够，有很多都是在工作中做的交流和沟通，我感觉有必要写一点什么。

我从不反对并且其实是鼓励用 AI 做一切事情的，包括写文章，但是我不管是读自己用 AI 写的文章，还是读组内同学用 AI 写的文章，总会有种还是没那么讲人话的感觉。这里怎么说，即使我认为我用了世界上指令遵循能力最强的 GPT5.5 xhigh 模型，写清楚 prompt 让他完全模仿我自己的写作风格，去写一点人话的感觉，但是始终还是到达不了那种味道。我感觉他的上下文还是不够多，毕竟我自己写下的文字，他的上下文可能是我二十多年的经历与历史，纵然 AI 训练的时候汲取了全人类的历史，但是他却对我知之甚少。因为我在互联网上留下的名字不够，我在互联网上留下的文字不多，就算留下，那也是我的文字所体现出来的我，可能仅仅反映了 0.01% 还不到的程度。所以可能 AI 最了解的是留下大量文字的作家？比如鲁迅？

AI 能写出很精致符合结构化的文章，但是能够准确表达清楚关键点的其实很少，因为假如我自己写的话，我会只突出最关键的部分，其余的地方略讲，当然，我也可以给 AI prompt 让他能够在哪里突出重点，但是他的表达方式总是不会完全贴切我想要写的风格。

文字本身是一种对话，AI 写的东西冗余度过多，我已经完全读不完了，但是我仍然期望应该有一种什么样的形式，能够让 AI 去产出确实能够稳定像真人一样的写作文章，我认为在技术文章领域应该是存在的，如何把一件事情真正地讲清楚，讲到真人真正会关心的重点，或许 somewhere in the wild 会有一些 skill，目前我自己试验的效果还并不是那么令我满意。

我目前大部分的亲自手打，都是在给 AI 写 prompt，与其只与 AI 对话，不如也在这里敲下一些文字，则是对和所有本文的读者所进行的对话。

所以话说回来，为什么会有 agent 框架？其实在现在这个时代，确实没有那么强烈的需求必须要有一个公共的 agent 框架，这里其实是分为很多不同的角度的。

首先，我们假如要造一个 agent，那么最灵活的做法是直接对着模型的 API 去 vibe 出来一个你想要的流程，首先你想出来你需要的这个 agent 的产品形态，然后和 codex cc（claude-code） 等进行对话设计整体的链路执行等，加上各种 tools skills mcp 各种上下文管理，我感觉最多花一个小时，你就能把这个 agent 不错地 run 起来，根本不需要 agent 框架。当然这里你也可以选用 agent 框架比如 langgraph agno crewAI autogen 等，好处是复用已经被重复验证的逻辑，坏处是你需要先学习框架本身，vibe 的时候 codex cc 他们也要去学习框架本身，然后所有的功能实际上都要受制于框架所暴露出来的能力。

其次，也是我一直反反复复在工作中和大家交流过的点，那就是大家都叫 agent，但是有些 agent 其实不太是一回事，我可以将 agent 划分为 local/开发环境下的 agent 以及线上环境的 agent，其中前者的特点是 agent 天然能够访问 file system 以及 shell，有着更为全面和灵活的环境，后者则是非常受限的线上环境，执行代码必须严格在沙箱中，文件系统相关能力则要通过挂载 COS 来实现，网络也要做隔离处理。对于前者来说，需要 agent 框架吗？如果你要做一个帮你研究分析股票的 agent，每天在本地定时跑，拉取全网相关的数据各种分析，你会用 langgraph agno crewAI autogen 对着 LLM API 写一个 agent 然后写各种流程或者各种逻辑吗？你会吗？我不会，我会用 codex 或者 cc 写纯的 prompt，用一个 github repo 来管理所有相关的 state，所有需要的 memory、skills 等状态全部落到合适的文件中进行管理，连常用的 prompt 本身都通过 git 来进行管理，这就是 https://github.com/WineChord/invest 所要表达的想法，我在 repo 里面有一个类比，那就是我的这个仓库本身就像一个 operating system，而 codex 这种 agent 则是电，我这个 repo 不被 codex 读取并操作时，他就是一个静态仓库，而用 codex 在上面开启一个会话，他的一切流程都能被自然地重新运作起来（那从这个角度说，这个仓库应该是整个计算机，operating system + 磁盘，哈哈），而 codex 本身是完全 stateless 的，我不需要利用任何之前的会话，我可以在仓库上开一个新的会话，来从 repo 本身去恢复任意想要的 state。并且，我并不用 codex 的 memory 功能，而这个 repo 本身，通过 AGENTS.md 里面的相关 prompt，我可以达到这个 repo 自己去做程序性记忆的效果，甚至，我完全通过 AGENTS.md 中的 prompt，去做自进化能力（自进化 skill，自进化仓库本身的代码），在 agent 下，prompt 其实已经是一种动态编程语言了，agent 代码本身是固定的，但是当 prompt 通过模型推理后的各种步骤操作，实际上就已经把 prompt 本身做了 just-in-time compile + 执行了，并且这种动态是超乎寻常的那种动态。

所以，什么时候需要 agent 框架？其实就是线上场景，每个大公司内部都会考虑研究开发一套使用的统一的 agent 框架，无他，因为他们要做 agent 服务的话，需要纳入整个服务治理体系当中，做服务发现，流量监控，日志采集与上报，链路追踪，这些所有东西背后都是一个个的内部基础设施组件，所有 agent 团队当然可以自己去把所有这些组件对接一遍，踩一遍所有的坑，但是这些东西必将要收敛，因为确实没有必要重复踩坑与造轮子，公司的基础设施已经收敛了，可以预见的未来都会非常稳定，那么你们每个团队为什么要做不断重复的劳动去各自重复对接一遍所有的这些组件？所以大型公司内部会造 agent 框架，比如字节造了 eino，google 造了 adk，我们造了 trpc-agent-go。

为什么带一个 trpc 前缀？因为我们之前是做 trpc 的，腾讯使用的 RPC 框架，所以 trpc-agent-go 其实带有一些 trpc 的基因，最关键的一点就是可插拔性，非常灵活的可扩展性，不管是 Agent、SessionService、MemoryService，还是背后的存储、CodeExecutor，全部都是 interface，可以自由的引入实现来替换各种组件，从而做强大的生态化。

所以，trpc-agent-go 带着 trpc 的基因，他们是面对的线上的场景，你不太会想在你的 mac 上或者你的开发机上用 trpc-agent-go 去写一个 agent 在那里跑的，你为什么不用 codex 呢？你为什么不用 cc 呢？

所以，也是因为这些原因，很多端侧以及开发环境的 agent 根本不需要 trpc-agent-go，也根本不需要任何的 agent 框架，你看 codex 用什么 agent 框架了吗，他的代码都是开源的，cc 呢，他也“开源”了，跟别说司内的 codebuddy workbuddy 了，对于 cli 以及 mac app 这些来说，agent 框架是根本不被需要的。

所以这里也自然而然地能看到一些很多这两种场景的不同与冲突。我个人能观察到的非常显著的趋势是，local/dev 环境的 agent 能力在全面胜出线上环境的 agent 能力，这是不可阻挡的事实，因为线上环境的 agent 被阉割的过多，不管是 shell 执行还是网络访问，都被限制了过多，原因就是为了安全，尤其是线上环境 agent 没有持续纯粹的作为第一公民的 file system。

codex 的能力已经强大到让我认为这将是改变这个世界上所有工作的工具（cc 也是），所有的工作，都会被 codex 给颠覆掉，因为我始终不考虑安全性地让他完全接管我的电脑，我的 APP，我的浏览器，我看到了他的无穷无尽的令人叹为观止的能力。但是云端 agent 却始终难以做到这一点，包括 codex 自己的云端 agent。

说到这里，我想说很有趣的东西，codex 一开始做的就是纯云端的 agent，太过于超前，内部响应平平，后来跟着 cc 后面做了 codex-cli，在 cc 已经把各种 subagent 玩的花里胡哨的时候，codex-cli 还在穿着开裆裤修各种 bug，但是我在 2025.9 开始使用 codex 之后，就几乎完全抛弃了 cc，因为 codex 使用的 gpt 模型是我见过的迄今为止指令遵循能力最强的模型，我就是纯口嗨，没做过一丁点严谨严格的 benchmark，纯纯靠自己和各种模型手动体感聊天使用来感受。而且我感受的速度和直觉很快，往往用几轮我就能体味出来各个模型之间的尿性，比如 gpt 模型画 html draw.io 等各种用代码表示的展示面非常烂（但是生图的 image 2 已经完全超出预期了），claude 则是前端艺术家，降智幻觉者，gemini 不管是 pro 还是 flash 都是异常的快，但是总有种不上不下的感觉，数学相关的公式渲染在他们的界面上偶尔会崩（ChatGPT 数学公式完全不会崩），然后偶尔我还能看到他因为数据没洗干净而吐出来的奇奇怪怪的文字。

所以整体的趋势其实是云端 agent 在往本地 agent 发展，就像 cursor 他一直都有云端 agent，但是很少人用（我是不用，你呢？），本地则是从 cli 一直发展到 native 的 app，发展出来越来越好用的 browser use 和 computer use。我相信他们会越来越好用，直到把所有用电脑的人全部都取代掉。

那线上场景 agent 的未来呢？需要 openai 的 agent builder 那样的东西吗？还是所有的代码靠 codex 去生成然后测试发布上线就完事了？明显后者效率会更高。

也正是这种趋势，很多 agent 热门的东西，其实肇始于 local/dev 环境下的 coding agent，比如 skills 是很典型的东西，他强烈依赖于 file system，导致线上 agent 其实很难优雅地支持 skills，因为他要引入 file system 以及 code execution 环境（？你说你要在线上环境的机器里面存 SKILL.md 并用那个什么网络和 binary 都没有的环境执行 python3 xxx.py ？）但是这些东西火了，做 agent 框架的也要跟进，然后我们就发现了这种显著的区别与不同，并着实踩了一些坑。其实 skill 这种能力在 coding agent 侧，比如 codex，我认为不实现在代码中，用纯 prompt 做描述也能搞，他们都实现在代码中无非是适合在 tui/app 等交互侧做 skill 相关的显式管理。而线上 agent 框架的用户，他们想要用 skill 功能，就要在除了 agent 服务之外，苦哈哈地部署额外的 sandbox 环境，并使用 COS 挂载磁盘，然后各种处理与调试。那么为什么不换个思路，可以直接转发请求到一个 sandbox 环境，里面直接运行 codex 呢，大家都不需要用 agent 框架写 agent 服务了，这里的主要问题我感觉是怎么处理 codex 本身链路的可观测性以及数据存储吧，毕竟确实不是所有业务都能接受 session 数据和 memory 数据等都存在磁盘上的。

所以可见的未来，线上 agent 必定还是会有他所存在的空间，agent 框架也有他发展的一席之地，司内的各种业务用户也是着实赏了一碗饭给我们吃，感谢我们的衣食父母。