AI 应用系统：终端层 — 自建还是复用
上一篇讨论编排层时给出一个判断：大多数项目永远不需要编排层。那对于不需要编排层的项目来说，终端层呢？答案同样是克制——绝大多数项目根本不需要自建终端。
终端层是"门店"
回到第一篇的定义：终端层是消费者直接使用的 AI 工具，是价值的最终交付点。用四层的比喻来说——模型层是工厂，网关层是批发商，编排层是消费 token 的公司，终端层是门店。消费者不关心工厂的流水线怎么布局、物流走哪条路线、管理层怎么开会。他们只关心门店里的商品好不好用、价格合不合理。
这意味着终端层的设计逻辑和其他三层完全不同。模型、网关、编排都是基础设施，面向的是开发者；终端层面向的是最终用户。评价标准不是"接入了多少个模型"，而是"用户愿不愿意每天用它"。
2026 年的终端生态
2026 年可用的成熟终端产品比两年前多了不止一个量级：
| 类别 | 代表产品 | 适合场景 |
|---|---|---|
| 通用对话 | ChatGPT、Claude、Gemini、Kimi、豆包 | 日常问答、内容创作、信息检索 |
| 编程助手 | Cursor、Claude Code、GitHub Copilot、Windsurf | 代码生成、项目级重构、Debug |
| 知识库问答 | NotebookLM、Perplexity、秘塔 | 文档分析、研究辅助、事实核查 |
| 工作流工具 | Coze、Dify（终端部分）、Zapier AI | 自动化流程、业务集成 |
| 行业专用 | 法律、医疗、教育垂直产品 | 专业场景、合规要求 |
需要注意的是，ChatGPT、Claude 这类产品是包含模型、网关、编排、终端全部四层的完整系统。本文讨论"复用终端"时，指的是以这些产品的终端能力作为入口，接入自己的业务逻辑——而非将它们视为不可拆分的整体。市面上已经有成熟的方案（如 OpenAI 的 Assistants API、Claude 的 Projects 功能）允许在复用终端界面的前提下注入自定义模型、知识库和行为逻辑。Benedict Evans 将这种趋势称为"ChatGPT 的围墙花园"——终端产品正在变成平台，复用不再是零和选择。
这些产品之间的竞争非常激烈。每个季度都有重大功能更新：流式输出已经成为标配，工具调用展示（思考链可视化）越来越精致，多模态输入（图片、音频、代码文件）基本普及，对话历史管理愈发成熟。
对一个创业团队来说，这些终端能力能覆盖 80% 以上的用户场景。
自建终端的真实成本
完整功能的 AI 终端远不止一个聊天框。以下是实现"及格线"功能所需的工程投入：
| 功能 | 工程复杂度 | 说明 |
|---|---|---|
| 流式渲染 | 中 | SSE 连接管理、打字机效果、连接中断重连 |
| 工具调用展示 | 中高 | 思考链可视化、工具调用状态、结果折叠/展开 |
| 多轮对话 | 中 | 上下文管理、编辑/撤回消息、分支对话 |
| 文件上传预览 | 中 | 多格式支持（图片/PDF/代码/视频）、缩略图生成 |
| 对话历史 | 中 | 存储、搜索、导出、多设备同步 |
| 身份认证 | 低中 | OAuth、Session 管理、权限控制 |
| 跨平台 | 高 | Web + iOS + Android + IDE 插件 |
| 可观测性 | 中 | 用户行为追踪、错误监控、性能指标 |
以上是"能用"的清单，不是"好用"的清单。每个功能背后都有大量的 edge case。举一个例子：流式渲染看起来简单——创建一个 ReadableStream，收到 chunk 后 append 到 DOM 上。但当用户在网络不稳定时快速发送多条消息，同时每条消息都在流式输出，同时中间一条消息被用户编辑重发——队列管理、滚动锁定、输入状态的冲突处理会迅速变成一团乱麻。
一个自建终端从 MVP 到生产可用，大约需要 2-3 个前端工程师 3-4 个月的时间。之后每个新功能（Agent 模式、多模态输入、自定义指令）都需要持续追赶成熟产品的标准。
什么时候复用
判断标准很简单：核心价值在终端里还是终端外？
| 场景 | 核心价值 | 终端策略 |
|---|---|---|
| 用 AI 辅助内容创作 | 模型能力和提示词质量 | 复用 ChatGPT/Claude |
| 内部知识库问答 | 知识库内容和 RAG 质量 | 用 NotebookLM/Perplexity |
| AI 编程助手 | 代码理解和上下文感知 | Cursor/Claude Code |
| 客户支持机器人 | 后端逻辑和知识库 | 复用成熟聊天 UI + API |
| 把 AI 嵌入现有产品 | 现有产品的核心体验 | 自建终端 |
| 2C 垂直 AI 产品 | 独特的用户交互模式 | 自建终端 |
2026 年的成熟产品已经不只是"聊天工具"，它们逐步开放了插件系统和 API。ChatGPT 支持自定义 GPTs，Claude 支持 Projects 和 Artifacts，Cursor 有 Rules 和自定义模型。这意味着可以在复用其终端能力的同时注入自己的业务逻辑。复用不是"用别人的品牌"，而是"用别人的终端做自己的功能"。
什么时候自建
以下三个条件是"需要自建"的充分信号：
1. 核心交互模式不是对话。 如果用户的主要操作是画流程图、编辑表格、拖拽组件，聊天框只是辅助交互方式，那现有的通用终端并不适用。需要把 AI 能力嵌入到操作界面中，而不是强迫用户在聊天框和产品界面之间来回切换。
2. 产品需要深度集成到用户已有的工作流中。 Slack 里的 AI 助手、Notion 里的写作助理、Figma 里的设计 Agent——这些场景的终端不是独立的网页，而是嵌入到宿主应用里的组件。复用产品做不到这种集成。
3. 品牌即壁垒。 如果 AI 界面的视觉风格、交互语言、用户体验是产品差异化的核心组成部分，那就不能外包给第三方终端。这与"功能追赶"不同——不是在复制 ChatGPT 的功能，而是在做 ChatGPT 做不了的事情。
三个条件同时满足才需要自建？不，满足任何一个就足够。
自建的合理范围
大多数需要自建的团队，实际需要自建的只是终端层的前半部分——交互界面。后端能力依然可以复用：
- 模型调用→ 走网关层，不需要自己对接模型 API
- Agent 协作→ 走编排层，不需要自己实现多 Agent 调度
- 知识库检索→ 用 RAG API 或现有平台
- 用户认证→ 用标准 OAuth，不需要自建
这就是四层架构的价值：只需要自建终端层这一层，其他三层全部复用现成的。
我自己在做产品时，终端层用纯前端方案构建（不依赖特定框架），模型调用全部通过网关层的统一 API，Agent 逻辑走编排层协议。前端只负责三件事：渲染流式输出、管理对话状态、提供用户输入方式。后端复杂度全部被下层掩盖了。
终端层的新陷阱
功能追赶是最常见的错误。团队开始自建终端后，会不自觉地以 ChatGPT 为对标：它加了语音输入，我也要加；它支持了图片生成，我也要支持；它出了 Mac 客户端，我也要出。这种追赶是无限的——OpenAI 和 Anthropic 都在全力投入终端，创业团队不可能在功能数量上超过它们。
低估渲染复杂度是另一个普遍问题。AI 终端的渲染跟普通前端应用完全不同：输出不是一次到位而是流式增量到达，内容类型不固定（文本/代码/表格/图片可能混杂在同一次输出中），用户的每一次输入都可能触发一个长达数十秒的状态变化。普通前端的状态管理范式在这种情况下不堪一击。我见过不止一个团队把 AI 终端做成 React 组件后发现，每次流式渲染都触发全组件重绘，解决方案是在虚拟 DOM 之外再维护一层手动 DOM 操作。
过早跨平台。Web 端还没做利索就启动 iOS 和 Windows 客户端的团队，最后往往什么都没有交付。一个 Web 端做到 90 分，比三个平台各 60 分更有价值。
总结
终端层的决策框架可以简化为两阶段判断：
第一阶段：必要性判断（满足任一即需要自建）
- 用户能否通过现有产品的终端能力完成核心任务？→ 不能
- 核心交互方式是否脱离聊天范式（画板、编辑器、拖拽等）？→ 是
第二阶段：可行性判断（必要性为"是"时才进入）
- 团队是否做好了持续追赶功能标准的储备？→ 是则自建，否则暂缓
终端是四层架构里最需要"延迟决策"的一层。 以复用起步，直到现有产品无法满足用户需求时再自建。到那时，已经有足够多的用户数据和场景理解来指导自建的方向，而不是猜测用户需要什么。
最后回顾整个四层架构的建设顺序：
- 模型层 — 选提供商，不必自建
- 网关层 — 尽早建立统一入口，不必自建（有成熟开源方案）
- 编排层 — 只在需要时引入，不一定需要
- 终端层 — 最晚决策，能复用就复用
四层里，最不值得自己写的反而通常是团队最先动手的那一层。
参考
- Building Effective Agents — Anthropic, 2024
- Emerging Architectures for LLM Applications — a16z, 2023
- Generative AI Lens - AWS Well-Architected Framework — AWS, 2025
- The Walled Garden of ChatGPT — Benedict Evans, 2025