25.1 起步决策树
模型: gpt-5.4 (openai/gpt-5.4) 生成日期: 2026-04-01 书名: AI编码智能体 章节: 第25章 — 构建你自己的智能体 Token 消耗: ~4,400 输入 + ~1,400 输出
如果你想构建自己的智能体，第一步不应该是罗列功能，而应该是画一棵决策树。功能清单会诱导你不断往系统里塞东西：更多工具、更多模型、更多模式、更多自动化。决策树则会逼你先回答一个更关键的问题：你到底要造什么样的系统？
这一章的重点不是赞叹 OpenCode、Oh-My-OpenCode 或 Claude Code 已经有多复杂，而是帮助你做出一个理性的起步架构。很多智能体项目不是死在实现能力不足，而是死在最开始的范围选择错误。
25.1.1 第一条分叉：Fork 现有宿主，还是从零开始？
对大多数团队来说，这是杠杆最大的一步。
如果你的主要创新点并不是宿主本身，而是编排、提示词、工作流、权限、技能系统或界面体验，那么基于现有宿主扩展通常更合理。比如以 OpenCode 为底座，你可以直接继承对话循环、模型接入、工具接口、会话处理，很多时候连 MCP（Model Context Protocol，可理解为模型与外部工具之间的标准连接协议）也已经具备。这样能省下几个月基础设施时间。
只有在你能明确说出“现有宿主在哪些架构前提上与我冲突”时，从零开始才值得。比如你要做的是极简本地智能体，不希望有太多抽象层；或者你的目标场景非常窄，不是通用软件工程，而是固件修复、基础设施值班手册、合同审阅之类的专门工作流；又或者宿主对于工具系统、会话模型、界面结构的假设会直接妨碍你。
一个实用判断是：如果现有宿主对你是“70% 加速，30% 束缚”，就拿来用；如果是“30% 加速，70% 束缚”，就重建。
25.1.2 第二条分叉：单模型深耕，还是多模型并行？
第二个核心问题是模型策略。
单模型深耕，是指围绕一个主模型族做深入优化。你的提示词、工具描述、上下文压缩、重试逻辑、输出格式，都会针对它调优。这样往往最容易在早期做出强体验。很多后来支持多模型的系统，起点其实也是这种方式。
多模型并行，则意味着你从一开始就做 provider（模型提供方）抽象和 capability（能力）抽象。听起来更通用，但代价很高。不同模型在工具调用稳定性、上下文长度、价格、延迟、多步指令服从性上差异很大。一个过早设计出来的统一抽象层，很容易变成 lowest common denominator（最低公分母）：谁都能兼容一点，但谁都没被真正优化好。
如果你当前目标是验证体验质量，先单模型；如果你做的是平台型基础设施，多模型可以更早考虑。即便如此，也最好先选一个主模型作为优化基准。所谓“支持很多模型”，并不等于“在任何模型上都表现优秀”。
25.1.3 第三条分叉：助手，还是自主执行者？
这条分叉本质上是在问：人要不要持续在环。
助手型系统通常处理较短的任务链，人始终靠近控制台，关键动作需要确认，结果也会频繁复查。自主执行者则更像拿到目标后，连续执行较长链条，尽量少打断人。
高自主性当然诱人，但它会抬高几乎每一层设计门槛。你需要更强的停止条件、更好的失败恢复、更完整的验证闭环、更清楚的成本控制，以及更细致的信任校准。换句话说，自主性不是单个功能，而是很多枯燥但关键的机制叠加出来的系统属性。
如果你是在做第一个智能体，默认更适合从助手做起。一个可靠的半自主系统，往往比一个经常跑偏的高自主系统更有价值。
25.1.4 第四条分叉：产品，还是平台？
另一个常见误区，是太早把自己定义成平台。
如果你在做产品，核心目标是整体一致性。工具集更克制，行为更有主见，文档更容易写，支持成本也更可控。
如果你在做平台，你就必须提供扩展点：插件、钩子（hook，可理解为在生命周期特定位置插入自定义逻辑的接口）、第三方工具接入、版本兼容承诺，以及一定程度的生态治理。平台确实能带来杠杆，但它带来的不仅是能力，也是长期义务。一个插件 API，不只是方便开发者的接口，更是一份未来维护承诺。
不要因为“平台听起来更宏大”就选平台。只有当外部扩展能力本身就是产品论点的一部分时，才值得在早期投入。
25.1.5 第五条分叉：单智能体，还是多智能体？
这是很多人问得过早的问题。
单智能体系统更容易理解、更便宜、更容易调试。多智能体系统在某些任务天然可拆时会有价值，比如把探索、检索、实现、审查分成不同角色并行处理。
但多智能体也会引入委派逻辑、上下文传递、结果合并、重复劳动、假设不一致、Token 成本成倍增长等问题。如果你的单智能体还经常读错文件、计划漂移、验证不足，那么加 subagent（子智能体，即被主智能体派出去执行局部任务的独立执行单元）往往不是解决方案，而是把混乱放大。
比较稳妥的规则是：
- 默认先单智能体；
- 先用角色提示词模拟分工；
- 只有当某类任务反复证明“明确拆分角色有收益”时，再引入真正的委派。
25.1.6 一棵可操作的起步树
你可以把起步问题压缩成下面六问：
- 这是学习或实验载体，还是长期维护产品？
- 如果是产品，现有宿主能不能显著加速首版？
- 我需要先把一个模型做到最好，还是先追求可移植性？
- 用户是否会长期在环，还是系统要长时间自主执行？
- 第三方扩展是现在就必需，还是以后再做？
- 现在是否已经存在明确需要多智能体的工作负载？
每个分叉本质上都是权衡：杠杆 vs 架构纯净、深度优化 vs 可移植性、自主性 vs 可控性、扩展性 vs 简洁性、编排能力 vs 运维清晰度。
没有放之四海而皆准的唯一正确答案，只有对你当前阶段更合适的答案。
25.1.7 对大多数构建者的默认建议
对大多数团队而言，最好的起步路线其实很保守：以现有宿主为基础扩展、优先围绕一个主模型深耕、先保持单智能体、初始工具集尽量小、平台化野心往后放。
这条路线不炫，但学习速度最快。它让你先看到真实失败模式，再决定哪些抽象值得固化。因为智能体系统里最容易做错的，往往不是具体功能，而是过早抽象。
真正推进得快的团队，通常不是一开始架构画得最大的团队，而是最少做出不可逆决策的团队。