大家好，我是静远，一个天天在用AI做一人公司的架构师。
文末有我的微信，需要我同款的一人公司资料包（工作空间总览、AGENTS.md 模板、知识库目录模板，还有快 20 个经典场景提示词模板）的朋友们，加好友备注领资料即可，打包直接发送。
最近一周，我干了一件挺大的事。
我把支撑我整个Agent军团的地基，拆了，重新打了一遍。
搓出来一个Agent中台。
这件事的起因，说起来有点不好意思。因为把它逼出来的，不是什么宏大规划，是我自己那堆skill，先撑不住了。
今天这篇文章，是这个系列的第一篇。我先讲清楚两件事，为什么需要一个Agent中台，以及这个中台的技术底子是怎么选的。后面的文章，再一层一层拆里面的模块。
一. 先说痛点，skill 这套东西跑到头了
先交代一下背景。
我的公司就我一个人，业务全靠Agent跑。写文案的、起标题的、做口播视频的、剪片子的、周报复盘的，大大小小十几个skill，各管一摊，跑了几个月。
讲道理，这套东西前期是真的好用。一个需求写一个skill，丢给通用Agent，它自己读说明、自己干活，我验收就行。
但是跑得越久，不对劲的地方越多。
第一个不对劲，是模型。
skill这个东西，你没法给它挑模型。
我宿主的通用Agent用什么模型，它就用什么模型。写标题这种明明该交给推理强的模型慢慢琢磨的活，和剪视频里跑数据的粗活，用的是同一个模型同一套参数。
系统提示词也一样。我给起标题的活写了一版很满意的提示词，但在skill体系里，它没法作为系统提示词生效，只能混在任务说明里，模型爱听不听。
调采样参数？温度、思考深度？更没有地方设。
带来的结果很直接。该慢思考的地方它快思考，内容质量上不去。该便宜快跑的地方它用贵模型磨，Token哗哗地烧。
而且通用Agent跑skill的方式，每一步都是读说明书、想、试、错、再试，全程都在烧Token。很多坑它每个新会话都要重新踩一遍，我只能在skill里一条条攒“判例”，告诉它别再掉进去。
第二个不对劲，是重复。
这个是我做了一次全面盘点才看清楚的，看完有点沉默。
光TTS配音这一个能力，我在5个skill里各写了一遍对接指引，加起来7处。
同一个音色，在两个地方各写死了一遍。同一句TTS语气指令，前后出过三个口径。改一次语气，我得追着改三个文件，漏一个，出来的声音就不对。
ASR语音识别更离谱。3个skill，3条技术路径。一个走本地funasr服务，一个用whisper.cpp，还有一个用mlx版本。为什么会有三条？因为它们是三个不同时期的我，各搓各的，互相不知道对方存在。
BGM混音，4套各自实现的配方。同一首曲子，被两个skill各自引用了一遍路径。
封面生成器，3套，互不共享。
这些还只是我盘点出来的。没盘到的角落里还藏着多少，我不敢想。
信息散成这样，维护就是灾难。供应商换了个接口，我要全局搜一遍哪些skill会死。想统一换个音色，改完永远不确定有没有漏网的地方。
第三个不对劲，是账。
我的业务需要记台账。哪条内容发了、哪个素材用了、哪条视频出了多少期，这些都是经营数据。
盘点下来，7个skill，7种记账办法。有的记在markdown记忆文件里，有的记在文件头的元信息里，还有更野的，靠数目录里的期号倒推。
没有一种能查全量。
我想回答一个特别朴素的问题，这个月我到底产出了多少条内容，都得挨个目录去翻。
第四个不对劲，是我想要的东西，skill给不了。
我越来越需要一个东西，就是能随时捏一个专用Agent出来。
写标题的Agent，就该挂着我那版标题提示词，配上推理强的模型，温度调低。写口播文案的Agent，就该换成另一个模型，挂上情绪文案的系统提示词。从提示词到模型到参数，每个Agent自己一套。
再往后，我还想把Agent和视频能力串成流水线。文案Agent写完稿，自动接TTS配音，接字幕，接BGM，一条命令出片。
这种事，skill体系里想都不要想。
二. 所以，中台是什么
把上面四个不对劲放在一起看，答案其实自己浮出来了。
更聪明的通用Agent，解决不了这四个不对劲。我缺的，是一个稳定的地基。
模型谁都可以调，提示词谁都可以定，TTS、ASR、生图、搜索这些能力对接一次全军团复用，数据统一记账，专用Agent随用随捏，流水线想串就串。
这个东西，就是Agent中台。你可以理解为，Agent军团的后勤基地。前线的skill怎么打都行，粮草、装备、军饷，统一从这里出。
于是就有了它，一个叫agent-platform的命令行工具。
长这样。六个命令。
mllm是多模态接入，七种能力，对话、向量化、TTS配音、ASR识别、生图、生视频，外加一个决策评估。全部统一接口，供应商在配置里切换。
video是视频处理，17个子命令，从切片、拼接、字幕这种原子操作，到自动字幕、翻译配音、口播配音这种组合管线。
search是联网搜索，接口统一，背后接了两家供应商。
ledger是台账，记录、列表、看单条、算条数，业务数据统一落库。
agent是专用Agent，一个toml配置文件就是一个Agent，系统提示词、模型、采样参数、思考深度，全在文件里，改完即生效。
workflow是工作流编排，把Agent和各模块能力串成流水线。
还有一层能力藏在底下，相同请求的结果缓存。完全相同的调用直接回放历史结果，对调用方透明，重复的活不重复烧钱。
这些模块现在加起来，128个Go文件，1万7千行代码。
三. 技术选型的三个为什么
中台要落地，得先选地基。我一共做了三个关键决策，每个都有理由，挨个说。
第一个，为什么用Go？
中台这个定位，注定了它要长跑。它是个天天被调用的服务，不是一次性脚本。
Go的好处，第一个是性能和资源占用。编译成机器码，内存占用小，一台最低配的云服务器就能带着跑，对一人公司来说，这是真金白银的差别。
第二个是部署。Go编译出来是一个单独的二进制文件，不挑环境，拷过去就能跑。这个特性往后看，中台从CLI长成API服务、要装到任何地方的时候，会越来越香。
第三个是给产品形态留了缝。你看上面那些命令的输出，全部走统一的输出通道，这是刻意设计的。今天它是命令行，明天把它包一层REST API对外，命令层的逻辑一行不用改。
第四个，说个和AI时代相关的，Go对AI辅助开发是真的友好。强类型，错了编译期就拦下来。测试是一等公民。格式统一，谁写出来都长一个样。我这些代码大半是Agent写的，人和Agent协作起来，摩擦特别小。
第二个，为什么用PocketBase管台账数据？
台账数据要落库，常规思路是装个数据库服务。但我一个人公司，为了记个账去运维一个MySQL，不值当。
PocketBase这玩意，你可以理解为，一个塞进单个可执行文件里的数据库。它基于SQLite，纯Go实现，跟着我的中台一起编译进同一个二进制，没有额外进程要维护。
建表靠版本化的迁移脚本，幂等执行，库表结构跟着代码走。
最香的是它自带一整套REST API和管理界面。这意味着我后续要把台账开放给别的系统、或者给自己开个页面看经营数据，基本是白捡的。
第三个，为什么选trpc-agent-go？
这是最核心的一个决策，Agent框架用什么。
业界框架技术路线分析
目前 AI Agent 应用开发框架主要分为两大技术路线：自主多 Agent 框架和编排式框架。
自主多 Agent 框架
自主多 Agent 框架体现了真正的 Agent（Autonomous Agent）理念，每个 Agent 都具备环境感知、自主决策和动作执行能力。多个 Agent 通过消息传递和协商机制实现分布式协作，能够根据环境变化动态调整策略，展现出智能涌现特性。
-
AutoGen（Microsoft）: 多 Agent 协作系统，支持 Agent 角色专业化和动态协商 -
ADK（Google Agent Development Kit）: 提供完整的 Agent 生命周期管理和多 Agent 编排能力 -
CrewAI: 面向任务的多 Agent 协作平台，强调角色定义和责任链模式 -
Agno: 轻量级高性能 Agent 框架，专注于多模态能力和团队协作
编排式框架
编排式框架采用工作流思维，通过预定义的流程图或状态机来组织 LLM 调用和组件交互。虽然整个系统表现出”智能”特征，但其执行路径是确定性的，更像是”智能化的工作流”，而非真正的自主 Agent。
-
LangChain: 基于 Chain 抽象的组件编排框架，通过预定义执行链路构建 LLM 应用 -
LangGraph: 有向无环图（DAG）状态机框架，提供确定性状态转换和条件分支
我最后选了腾讯出的trpc-agent-go。
几个理由。
一是它经过了生产环境验证，不是实验室作品。它从ADK、Agno、CrewAI、AutoGen这些优秀开源框架里吸取了很多灵感，把别人踩过的坑提前填了。
二是它的Agent形态足够全。LLMAgent基于大模型做工具调用和推理。ChainAgent链式执行多步任务。ParallelAgent并行跑多个专家。CycleAgent循环迭代自我优化。GraphAgent是图工作流。
这套东西刚好覆盖我的全部需求。业务Agent用LLMAgent，一个toml配一个。流水线用GraphAgent串节点。
三是工具生态。内置常用工具，支持Function调用和MCP协议，我自己的CLI能力往后包装成工具挂给Agent，路径是通的。
四是会话管理，支持内存和Redis持久化，有长期记忆，还有RAG检索增强。
五是可观测性，OpenTelemetry把Agent每一步的来龙去脉都串起来。Agent跑飞了能查到是哪一步飞了，这在排查问题的时候是救命的。
最重要的是：tRPC-Agent-Go 的核心架构是基于自主多 Agent 协作的框架，同时又提供工作流编排的能力。
一句话总结这套选型。Go保证它跑得动、铺得开，PocketBase保证数据有地方放，trpc-agent-go保证Agent这层不用我造轮子。
四. 已经跑起来的例子
光说架构都是虚的，讲个已经落地的。
我有一条每天出片的视频产线，拿选题写口播文案，TTS配音，配字幕，铺BGM，出成片。
以前这是个skill，ffmpeg、TTS、字幕的对接细节全写在skill说明里，Agent每一步都现学现试。
现在它是workflow模块里的一条五节点流水线。文案节点调用我的文案Agent出稿，配音节点做整段TTS，底片节点选素材拼接，合成节点做字幕对齐，音乐节点铺BGM出成片。一条命令，串行跑完。
而那条skill瘦成了什么样呢？它现在只负责三件事，选题目，调这条命令，记台账。它自己说明书里有一句话，我觉得可以原样念给你听。“本skill不再包含任何ffmpeg、TTS、字幕细节。”
工艺全部沉进了中台，修一次bug，全军团受益。想换音色、调BGM音量，改一处配置就行，因为参数的唯一事实源，就是中台配置文件里的那一段。
这就是中台该有的样子。
五. 但是，中台不是免费的
当然，讲道理，得把另一半也说清楚。
中台是有代价的。最大的代价是前期投入。这些能力在skill里是将就能跑的，搓成中台，每一层都要正经设计、写测试、管质量。这一周里，我相当一部分Token和人脑，都花在这上面。
还有一个隐性的管理成本。模块多了，架构纪律就得立起来。谁能依赖谁、供应商的方言代码只能出现在哪一层，这些规矩一旦破了，中台会更快变成新的烂摊子。
所以我的判断是这样。业务少、skill两三个的时候，别碰中台，那是过度设计。但凡你跟我一样，skill上了两位数、同样的AI能力对接了三遍以上、想查一笔业务账都费劲，那这个投入，值。
它本质上是一次搬家，从“每个skill自带厨具”，搬到“中央厨房统一配菜”。
搬家那天累，搬完之后，每顿饭都省事。
六. 这个系列会写什么
这篇文章是总纲。后面的系列，我会按模块逐个拆开讲，多模态接入层怎么设计统一接口，视频管线怎么分三层，专用Agent的配置文件怎么定，台账的表怎么建，工作流节点之间怎么传数据。
全过程的代码和踩坑，都会写出来。
我的立场一直没变过。过程是内容的母体，但过程得能变成别人也能拿走的东西，才算数。
Agent越强，越需要一个不随Agent换代的地基。
模型一年换一茬，提示词的写法月月在变，但你的业务能力，你怎么配音、怎么出片、怎么记账，是攒出来的资产。
资产要放在资产该在的地方。
不能放在Prompt里。
这个系列，我们慢慢拆。
你呢？有没有哪个AI能力，你已经在三个以上的地方各对接了一遍？评论区聊聊，我看看你家的账能对上来吗。
开头提到的领资料方式，扫码加我个人微信，备注领资料即可直接发送。
欢迎点赞收藏转发关注。
把你卡住的那个具体任务发我，我看看能不能拆成 AI 能参与的步骤。