课程 ID: 19295
描述:
话题概述:
半年前，我们交付了一个“看起来很惊艳”的 Agent Demo——能对话、能调用工具、能流式吐字。业务方看完很兴奋，说“我们也要接！”。但当真正进入接入阶段，问题才开始爆发：
业务方“以为只要调一下 LLM API”，实际要自己写 ReAct 循环、解析 tool call、处理 LLM 抖动重试；
业务方“以为前端就是接个 SSE”，实际要自己定义事件协议、自己实现刷新页面续流、自己处理多设备并发；
业务方“以为让 Agent 弹个表单很简单”，实际要自己设计 Component 协议、组件库、用户提交回流通道；
业务方“以为图片生成完丢给前端就行”，实际还要解决“如何把生成的图自动塞进画布让用户能编辑”；
最痛的是——每接一个新业务，前端 UI、后端 Loop、工具协议、产物管理全部要重写一遍。
我们对接过画布、文档、视频、客服、研发工具等多个业务线，发现一个共性结论：Agent 不是不能做出来，而是每个业务都在重复造一遍同样的轮子，且每一遍都做不到生产级。 业务方真正需要的，不是“再多一个 Agent 框架”，而是一套**“业务方只管注册自己的特殊能力，其余通用脏活全部不用碰”**的端到端解决方案——后端给 Agent Loop，前端给 UI SDK，中间用一套统一契约打通。这就是我们项目要解决的核心问题。
演讲题纲:
话题亮点：
我们最终用 “一条 API + 一个 SDK + 三个扩展点” 的架构，把业务方的接入成本从 “2 人月” 压到 “1 人天”。关键技术与攻关点如下：
1. Remote Agent Loop —— 把 Agent 推到后端，前端零负担
后端用 “POST 触发 + getStream 订阅” 的双通道模式，把 Agent 上下文持久化到 Redis，实现刷新页面/切设备/断网重连后的中断恢复。踩过的最大坑是：早期把 Flux 直接缓存导致内存泄漏，后来改用 streamId + 事件回放才稳定下来。
2. 前端 SDK 一个组件渲染完整对话 UI
基于事件溯源架构，把 thought / tool_call / tool_result / final / artifact 全部抽象成事件流，业务方塞一个 React 组件就能拿到流式渲染、Component 表单、Artifact 卡片、前端工具回调全部能力。最大的攻关是 SSE 心跳重连——45 秒心跳超时 + 指数退避，解决了网关层各种诡异断连。
3. 插件机制 —— 不同产物由不同编辑器打开
定义 EditorPlugin 接口 + PluginDispatcher 调度器，按 priority 自动匹配。Canvas 只是其中一个插件，Markdown / Video / Code 等编辑器都可以独立接入。这是这套架构未来最大的扩展点——产物与编辑器解耦，谁都可以接。
4. Component Tools（AskUser）—— 人在回路的真实落地
让 Agent 能弹出单选/多选/自定义输入/混合表单，用户填完后答案自动回流到 Agent 上下文。踩过的坑：早期用户提交后 Agent 不知道哪个工具调用对应哪个回答，最后用 toolCallId 做关联才解决。
5. Skill 管理三件套 —— 状态持久化 + 相关性卸载 + 用户绑定
用 SkillStateSerializer 把 Skill 状态序列化到 Session，同时引入“连续 N 轮没用过的 Skill 自动卸载”机制，解决 Token 预算爆仓问题。再加上用户维度绑定 + 对话内自动创建（Eat self dogfood），让 Agent 能力可以被业务方和终端用户双向沉淀。
6. MCP 工具动态注册 + Multi-Agent 工具化
ComfyUI 工具、子 Agent 全部 MCP 化，主 Agent 把“调用子 Agent”视作一次普通的 tool call，复用同一套 ReAct 循环，避免了业界常见的“主从 Agent 各写一套调度逻辑”的复杂度爆炸。
最大的踩坑教训：早期把“功能做全”当目标，后来才意识到——端到端的真正价值不在于 Agent 有多牛，而在于业务方“什么都不懂 Agent 也能用上 Agent”。