LLM 对传统工程的冲击
工程确定性与 LLM 概率性的交叉互补
- 能用明确代码写清楚的逻辑属于工程逻辑。
- 在规则难以完整枚举，或需要处理自然语言、文档等非结构化内容时，LLM 才有价值。
（反面典型例如用大模型点奶茶）
虽然方法论已经被广泛认可，但实现起来却不容易。
因为当下基于 LLM 的产品和技术架构仍处于早期探索阶段（虽然与传统技术相比发展速度快得不可思议，但主要聚焦于少数几个商业价值极高的方向）。
研发是个非常依赖过往经验的工种，多数人并不擅长颠覆式的技术创新，更习惯于在一个成熟框架内做少量方向的探索。
并且基于 LLM 的产品和技术架构，其耦合程度之高，远超传统产品，对现有产品与研发的分工合作是个很大的挑战。
所以我以产品 + 研发的双重视角，简单梳理下一个围绕 LLM 搭建的 Agent 产品可能遇到的问题和基本的思考流程。
强大的模型，粗糙的交互，万能 Chat 的局限性
结合业务设计一套能充分发挥 LLM 能力的交互形态是首要任务。那非 Chat 莫属了。
Chat 决定了一款复杂 Agent 产品的高能力上限，但 Chat 的交互体验是非常差的，我们对交互层的设计，就是围绕着 Chat 做能力抽象，核心是既保留 Chat 的高自由度，又尽可能地提高交互体验。
最经典的例子是在 Chat 之上加一些固定助手，提供快速触发任务的快捷入口，减少手动交互频率。这种优化看似很小，但极其重要，并且积少成多。我认为起码要优化到将原本 Chat 中 50% 以上的交互成本迁移到各种辅助工具中，才能算一款可用的产品。
Codex 作为通用 Agent 的第一梯队，设计上做了极大创新，包括废除代码视图的主入口、丰富的侧边栏、内置的终端和浏览器、任务的多种模式等等。
LLM 很强大，但能力极其单一，要充分发挥 LLM 和 Agent 的能力，将人的心智负担逐渐从自然语言中抽象出来，是一款好的产品交互形成的过程。
Agent 产品的交互设计，非常考验产品的想象力，大部分都是从无到有的设计，同样也考验产品对于 Agent 本身能力的理解和实际业务场景的理解，交互做不好就是个垃圾，Agent 能力再强也没用。
现在所有主打 AI Agent 在传统领域落地的产品，你打开它们的入口，只要是干巴巴的 Chat，一律都是垃圾。
沿着一条简洁的 Agent 主线去设计
Agent 的设计通常要兼顾各种任务，任务执行的维度经常是混乱的，例如有些要意图分析、有些要取特殊上下文、有些要调外部工具、有的需要循环 LLM，有些甚至都不需要 LLM。以工程思维解释就是无法做精准的抽象、封装、拓展（如果可以做就没必要设计 Agent 了）。
这种情况下，普通技术团队很容易设计出几种架构：
- 一刀切，固定流程
例如：前置上下文收集 + 统一意图识别 + 统一 Tools 列表 / 子 Agent / Skill + 统一 LLM 汇总。
方案虽然简洁，但牺牲了体验。很多任务不需要意图分析，统一加上会浪费 token，又增加耗时，功能拓展也受固定流程限制。 - 全耦合，任务定制
给不同的任务编排不同的 workflow，所有的流程耦合到一起，功能效果优先，但流程多了很难梳理，任务之间可能有冲突，不适合复杂的任务场景。 - 复杂架构
很多人喜欢设计一套复杂的架构，提供丰富的拓展方式去接入，但维护成本高，Agent 场景下很容易随时出现一些新的概念，与原架构相融很麻烦，Agent 架构还是要以简洁为主。
我的思路是保持主线简洁，先按任务的时效性分流：
- 短时效任务：用户需要立即拿到结果，每优化一秒，用户体验就会提升很多。
- 长时效任务：时间不敏感，执行 1 分钟还是 5 分钟差别不大。
用户输入"你好"，必须立即回复。
但有人困惑，如果提问确实涉及到某个内部知识，结合检索结果回复更优，要保证速度还是质量？
肯定是速度 （优先体验），不可为了展现能力的强大而牺牲体验，优化方向一定是先保证时效再分析如何提高质量，质量一定是先被牺牲后优化的，优先保证质量的是实验室的试验，不是产品。
主 Agent 的意图分析的目标要极其清晰，只暴露高频、边界清楚的能力，避免歧义，一般情况下做个常用 Tools 的简单循环即可，不要同时接入 Tools、Skill、MCP 等等。
例如 Skill 一旦触发，执行时间通常很长，所以 Skill 压根没必要耦合到主线中，所有的 Skill 都交给一个子 Agent 单独处理即可，主线只需要合理推断是否有必要调用 Skill 即可。
所有的支线统一封装进 Tools 中给主线调度，各自分发，这样我们就得到一条干净简洁快速回复的主线，以及通过 Tools 封装的支线，以及各个支线下封装的子 Agent、固定 workflow、Skill 等长任务。
Server Agent 的局限性与沙箱环境的建设
多数 Agent 会部署在服务端而非客户端，一个强大的 Agent 非常依赖端上（电脑）的系统级能力，例如文件系统、编程环境、网络请求甚至是浏览器调用，而在服务端极难利用服务器的系统级能力，持久化、安全性、并发方面的问题都很难解决。
所以 Agent 要建设复杂长任务的能力，独立的沙箱环境必不可少，我认为当下 Agent 标配起码是一个 Server Agent + 至少一个独立沙箱。
沙箱是一个概念吧，只要能提供端上系统能力，并且与服务端做隔离，无论是任何机器都可以称为独立的沙箱，是否要做任务隔离、自动销毁、开放多少系统能力完全取决于 Agent 的长任务特性。
沙箱可作为 Agent 支线中复杂任务的能力拓展端，例如将代码拉到沙箱去跑、自动写脚本运行、剪辑视频之类，要频繁进行 I/O 操作、网络请求和编程就可以作为扩展能力放进去。也可以直接将一个复杂的 Agent 与一个沙箱深度绑定，将入口放到服务端供主 Agent 调用即可。
固定流程编排（workflow）的重要性
如果你目前还抱着搞个超级 Agent 产品，底层设计通用型扩展插口（例如 MCP、Skill）来实现以 LLM 自由主导的 Agent 设计，是非常幼稚的，不亚于将一个发动机和四个轮胎装在箱子里，然后期望它能自己跑起来。
workflow 的主要逻辑由固定代码主导，LLM 辅助，适合步骤稳定、风险较高、需要明确验收的任务。动态流程由模型根据当前信息决定下一步，适合搜索、诊断、研究和其他难以提前枚举路径的任务。
实际系统很少需要在两者之间二选一。更可靠的方式是固定外壳包住动态执行。例如一项复杂任务可以稳定地分成：准备输入、校验权限、执行、验证结果、保存产物。中间的"执行"阶段允许 Agent 动态选择搜索、读取文件、调用工具或委派子 Agent，其他阶段仍由程序控制。
在现实中，workflow 的设计程度，与 LLM 基础能力的进步息息相关，曾出现过提倡以 workflow 为主导（保守派），和以自由 LLM 为主导（激进派），两个完全相反的思路。但就目前来看，虽然 LLM 能力屡破想象，但纯以 LLM 为主导的 Agent 设计仍然是效果很差的。
Tools、Skill、MCP 如何选择
1. MCP 可以直接放弃
MCP 没有必要再用，过于鸡肋了，它封装的维度非常狭窄，只提供基础描述和接口调用方法，作为独立模块过于单薄，作为 Agent 内嵌工具又很难掌控。
作为独立模块需要耦合业务 Agent 能力，放到 Agent 中又过于独立无法与 Agent 设计相融合，我宁愿把里面的接口扒出来放到 Agent 中作为基础 Tool 使用。
MCP 是一个中间态的产物，它促进了 Agent 从自然语言能力发展到复杂任务执行，在实际场景发挥价值很小。
2. Skill：封装外部能力的拓展
经过 MCP 的验证后，Skill 真正地将功能模块封装到 Agent 扩展中，可以理解为一个 LLM + 一个 Skill，就已经组成了一个专业的子 Agent，非常适合复杂的外部能力作为通用模块接入当前 Agent 系统的场景。
但也是有代价的，调用 Skill 会有更多的损耗，提高成本，执行时间长，适合对时间不敏感的长任务。
3. Tools：Agent 内部工具
无论是 MCP 还是 Skill，都是给 Agent 加上执行的能力，前两者的思想都是对能力做通用型封装然后交给 Agent 自发调用。相比之下 Tool 就是内部封装的能力，直接嵌入到 Agent 上下文中，与业务逻辑紧密结合，Tools 才是 Agent 基本能力的主要来源。
总结
可以按时效性理解，Agent 中 LLM 快速回复是秒级（1--5 秒），涉及 Tools 执行在分钟级（1--3 分钟），子 Agent 或 Skill 为异步长任务（5--30 分钟）。
这样你就能理解，你的产品中，应该以什么设计为主了。
附加 1：调优思路
有非常多技术上调优的角度，我提一些容易被忽略的角度。
可回溯性要覆盖整条执行链路
可回溯的链路是一切调优的基础，进入 Agent 后，无论是 workflow 还是动态流程，都要留存足够完整的执行链路信息。
Agent 动态流程的固化
纯 LLM 自驱的动态流程一定是很慢的，每次运行都会形成一条临时路径：读取哪些信息，做过哪些判断，调用哪些工具，如何重试，最终如何验证交付。
每次实时分析，成本高、体验差。之所以要实时是因为我们要猜测用户的意图，但随着产品投入使用，用户常用的能力一定是有限的几种，可以将最常用的能力抽象成新交互、新 workflow，引导用户快速使用，提高体验、降低成本。
附加 2：知识库
知识库是个很复杂的话题，更多请看我之前写的关于知识库的文章：
《别再优化 RAG 了，适配 Agent 的 LLM Wiki 知识库理念》
在 Agent 设计上我主要想表达：
- 无论企业还是个人，文档里真正高价值的内容只占很小一部分。低价值资料不会因为被交给 LLM 就变成高价值。
- 强大知识库 + 万能 Agent 的组合思路不可行。
- Agent 中大量知识依赖的场景一定是小众需求。
- 知识库对一般 Agent 的增强有限，除非是涉及大量知识的业务场景，例如智能客服。
- 把依赖大量外部知识、优化 RAG 检索作为增强 Agent 能力的方向，在效率、体验和性价比上都非常低。
附加 3：一套可以落地的最小架构
把前面的思路放在一起，最小架构其实很简单：
- 产品入口：Chat 保留自由表达，高频任务做成短路由跳过意图分析、消息增加表单交互，减少反复输入。
- 主 Agent：只负责快速响应和任务分发，接入少量高频、边界清楚的 Tools，保持主线简洁。
- 任务支线：统一通过 Tools 暴露入口。内部用固定 workflow、子 Agent 还是 Skill，由具体任务决定。
- 独立沙箱：承接需要文件系统、代码执行等系统能力的复杂任务，结果再返回产品。
例如用户要分析一份文件并生成报告，主 Agent 判断后交给对应支线，支线在沙箱中读取文件、执行分析、生成产物。产品展示任务进度和结果，主线仍然可以继续响应用户。
原创声明
原创文章，转载请注明作者和文章原链接，插图来源 AI 生成，关注公众号看更多文章哦！
内容创作 AI 自律声明
