Agent 架构选择

最近使用了一些 Agent 产品，也在想一个问题，Agent 这套东西到底更适合做成 BS，还是 CS。
我现在偏向 BS 一点。
主要还是因为，如果想做的不是一个个人外挂，而是一套团队里能复用、能慢慢沉淀下来的能力，那 BS 这条路会更好。
CS 它更适合个人使用，或者那些特别依赖本地环境的场景。

为什么通用智能体会让人觉得很好用

像 Openclaw 、Claude Code、Codex这类通用智能体，使用下来第一感觉一般都不会太差。
它好用的地方其实挺直接的：

1. 1. 它能把电脑、聊天工具和 Agent 连起来，通过聊天工具直接操作本机。

2. 2. 它有自己的记忆系统，用久了会越来越懂你。

3. 3. 它的 Skill 够多，很多事情都能接上。

这种体验对个人用户来说其实很有吸引力，因为它几乎就是围着“我自己”在长：我的电脑、我的账号、我的工作流、我的记忆。
但用下来会越来越觉得，这种好用很多时候是偏个人的，不太是团队意义上的好用。
因为里面很多东西，本质上就不太适合共享。

1. 1. 记忆是私人的，很多内容本来就不该暴露给别人。

2. 2. 很多能力依赖本地环境、登录态、文件系统，迁移起来很重。

3. 3. 同一个 Skill，换一台机器、换一个人，执行效果就可能不一样。

所以这类产品很容易让人产生一个错觉，就是体验很好，所以架构也应该这么选。
但这两个事情其实不是一回事。个人体验成立，不代表团队场景也可以照着走。

Agent 的核心不只是模型

现在再看 Agent，我会觉得真正有价值的东西大概分两层。

1. 1. 模型本身够不够强。

2. 2. Skill 体系做得够不够好。

模型当然重要，但真到了落地阶段，很多时候拉开差距的不是模型多聪明，而是 Skill 写得够不够清楚，边界稳不稳定，流程有没有沉淀下来。
尤其是用好的模型把 Skill 打磨出来之后，再让一个中上水准的模型去执行，很多场景下效果差距并没有那么夸张。
也就是说，最后拼的往往不是谁模型最强，而是谁把可复用的能力整理得更好。
如果这么看，架构问题其实也就变了。
重点不再只是客户端离本地有多近，而是：

1. 1. Skill 怎么组织。

2. 2. Skill 怎么被调用。

3. 3. Skill 怎么复用。

4. 4. Skill 怎么治理。

现有Skills类型

1. 纯提示词型 Skill

这种 Skill 本质上就是把一类任务的上下文、约束和输出格式写成一段高质量 Prompt。

2. 工作流型 Skill

这种就不只是提示词了，还会把执行步骤写清楚，把稳定的部分直接下沉到 MCP、API、命令行、脚本或者固定流程里。
到了这个阶段，模型其实不需要从零发挥太多，它主要是在做几件事：

1. 1. 判断当前是什么场景。

2. 2. 选择哪个 Skill。

3. 3. 在几个关键节点做决策。

4. 4. 调用已经确定好的工具和流程。

这种 Skill 会更接近真正能落地的东西。

3. 知识增强型 Skill

这种 Skill 会把检索增强能力放进来，执行的时候动态加载领域知识，比如公司制度、产品文档、历史案例这些内容。
它比较关键的一点是，不是把所有知识一股脑塞进上下文里，而是使用渐进式披露：

1. 1. 先保留少量元数据常驻。

2. 2. 具体指令按需加载。

3. 3. 真正相关的知识再动态注入。

这样做的好处很明显，就是能避免上下文爆炸干扰模型，同时又能把输出质量维持在一个专业水平上。

4. 组合编排型 Skill

这种 Skill 已经不是单点能力了，而是一个 Skill 会显式依赖或者调用其他 Skill，最后形成一个能力网络。
比如一个投资分析 Skill，背后可能就不是一个 Prompt，而是：

1. 1. 先使用「数据获取 Skill」。

2. 2. 再使用「风险校验 Skill」。

3. 3. 最后使用「报告生成 Skill」。

往这个方向走，其实就会越来越像微服务。Skill 不再只是一个技能，而是一组可以被编排的能力节点。

5. 代理协作型 Skill

这种就更进一步了，它不是只定义做什么，还会定义谁来做、什么时候移交、出了问题怎么回滚。
也就是说，它已经是按多 Agent 协作的方式来设计了，里面会带着路由规则、权限边界、状态同步这些东西。
这种 Skill 更适合复杂业务场景，因为复杂场景里往往不是一个 Agent 从头干到尾，而是不同角色分工协作。
从这个角度看，Skill 其实已经越来越不像一个简单的 Prompt 模板了，更像一个标准化能力单元。
而 Skill 一旦往知识增强、组合编排、代理协作这些方向发展，就会更适合服务化和平台化，而不是只挂在某个本地客户端里。

为什么更偏向 BS

1. Skill 一多，挂在本地 Agent 上很容易变形

理论上大家都希望 Agent 什么都能干，但实际上 Skill 挂得越多，模型选择就越容易偏。
常见的问题就是：

1. 1. 候选太多，容易选错。

2. 2. 描述接近的 Skill 会互相干扰。

3. 3. 上下文越来越长，推理成本越来越高。

4. 4. 每个人本地挂的 Skill 不一样，最后行为也不一样。

如果走 BS，就更容易按领域把能力拆开。
比如测试是一个 Agent，文档是一个 Agent，发布又是一个 Agent。
每个 Agent 只挂自己那点 Skill，反而更像专家，而不是一个看起来什么都有、实际经常选错工具的通用助手。

2. 真正有价值的能力，最后都应该能 API 化

如果一个 Skill 是稳定的、值得长期复用的，那它最后最合理的形态，多半不是只能在某个聊天窗口里被调用，而是应该能直接作为能力对外提供。

比如：

1. 1. 在 CI 里自动触发。

2. 2. 在页面上点一个按钮就能调。

3. 3. 在提测、发布、复盘这些流程里直接接进去。

一旦能力能 API 化，它就不再依赖某一个人的客户端，也不再依赖谁本地刚好装好了那一套环境。
这个事情对团队来说挺重要。
因为团队真正需要的，很多时候不是一个很强的聊天窗口，而是一组可以插进流程里的能力。

3. CS 前期看起来快，但后面容易一直背着隐性成本

CS 的优势主要是离本地近，所以早期做体验会比较快，很多事情接起来也直接。
但问题是，这种快有时候只是把复杂度藏到了后面。
后面常见的账基本都会慢慢冒出来：

1. 1. 复用成本高，能力容易绑在人和机器上。

2. 2. 治理成本高，Prompt、Skill、权限、版本都容易混乱。

3. 3. 排查成本高，不同环境下的问题很难稳定复现。

4. 4. 推广成本高，一个人能用不代表一群人都能用。

5. 5. 人员风险高，核心用户一走，很多经验也一起带走了。

这些问题在刚开始的时候往往不明显，因为那时大家更容易被“这个体验挺流畅”打动。
但如果目标是往后做成团队能力，这些成本基本都会回来。

4. BS 的好处，不只是形式变了，而是能力更容易沉淀下来

我偏向 BS，不是因为它只是把调用位置从客户端挪到服务端，而是因为它更适合做沉淀。
用了 BS 之后，很多事情会自然一点：

1. 1. 能力更容易变成组织资产，而不是个人外挂。

2. 2. Skill 更容易服务化，然后被不同入口复用。

3. 3. 权限、日志、版本、成本这些东西更容易统一管理。

4. 4. 后面新接一个页面、新接一条流程，成本也更低。

说白了，CS 更像是把人武装起来，BS 更像是把能力沉淀下来。
两者都能做事，但如果是团队建设，后者的价值会更大。

成本问题

1. 1. 如果主架构偏 CS，短期可能更容易把体验做出来，但后面大概率要持续为复用、治理、环境差异这些问题买单。

2. 2. 如果主架构偏 BS，前期会多做一点抽象和服务化，但这些成本不是白花的，它换来的是后面更低的边际成本和更强的组织沉淀。

结论

如果是做个人 Agent，CS 可以很强，甚至很多时候体验会更好。
但如果是做团队 Agent，或者说想做成一个能长期沉淀能力的东西，BS可能是更好的方式。

因为如果想要的不是某个人用起来特别爽，而是这套能力以后能被更多人稳定地用，能接进流程里，能持续沉淀下来。
从这个角度看，BS 更像是在搭地基，CS 更像是在给某个高手装外骨骼。