企业官网建设流程全解析

原文链接：1 个通用 Agent 循环，N 个 Skill SOP：拆解智能体编排的底层逻辑

现在提到豆包工作、TRAE、WorkBuddy，很多人会直接叫它们"办公 Agent"。但严格来说，这称呼只对了一半。

它们不是一个具体的"Agent"，而是一个平台入口。真正在后台完成做 PPT、写文档、跑代码、生成海报这些事的，是无数个更小的"窄 Agent"。

这些窄 Agent 如何被统一调度？关键不在某个更庞大的工作流图，而在一个通用 Agent Loop 加上一套 Skill 程序化 SOP（Standard Operating Procedure，标准操作流程）。

这个视角对开发者和产品人都很重要。选型时不应只看入口好不好看，而应关注循环稳不稳、Skill 好不好写、引擎好不好接。

宽平台与窄 Agent

一个办公 Agent 平台，内部往往有两层角色。

第一层是平台级通用 Agent Loop。它负责接收输入、理解意图、选择工具、调用 Skill、管理记忆、返回结果。

这一层与具体场景无关，对应的是 ReAct 范式里的观察-推理-行动循环。

第二层是窄 Agent。每个窄 Agent 只盯一件事：办公类如制作 PPT、撰写 Word、分析数据、策划方案；开发类如网站、小程序、日常开发；设计类如视觉海报、PPT 设计、品牌设计、视频生成。它们依附在通用 Loop 上，按需被加载。

可以把平台理解成一个发动机舱：通用 Agent Loop 是发动机，各种窄 Agent 是装在不同底盘上的专用车。

对平台方来说，这意味着新场景可以被封装成一个 Skill 快速接入，而不必重写整个系统。对用户来说，同一套聊天入口可以触达多种专业能力。

一次请求如何落到"做 PPT"上

以 WorkBuddy 的制作 PPT 为例，用户进入这个窄 Agent 至少有两条路。

第一条是自由对话：用户在聊天框输入"帮我做一份产品发布会 PPT"。平台先做一次意图识别，确认目标是制作 PPT，再加载对应 Skill。

第二条是显式入口：用户直接点击"制作 PPT"标签，意图已经暴露，平台跳过识别，直接加载同一个 PPT 专属 Agent。

无论哪条路，最后都进入同一个"做 PPT"的窄 Agent。这个 Agent 不自己重新造轮子，而是复用平台的通用循环。

意图识别在这里只是一个路由动作，真正的执行逻辑全在 Skill 里。这也说明，通用 Agent Loop 的健壮程度，往往决定了平台能承载多少种场景。

"专属"的不是编排，而是知识、引擎、格式

拆开这个 PPT 专属 Agent，能看到清晰的四层结构。

最底层是通用核心：Agent 循环、工具调用、记忆系统、任务编排、Skill 加载机制。这一层被所有场景共用，和"做 PPT"无关。

真正让"做 PPT"不同于"写代码"或"做表格"的，是上面四层：领域知识、领域引擎、领域格式、周边工具。

在 WorkBuddy 的例子里，领域知识是 tencent-pptx 技能包（位于 ~/.workbuddy/plugins/cache/workbuddy-builtin/tencent-pptx/，随版本升级分发），内含 SKILL.md 与 references/*.md（提示词、设计规范、组件文档、SOP）。

领域引擎是 @tencent/slidep（手，位于全局 node 包 lib/node_modules/@tencent/slidep）；领域格式是 SlideDSL 与 @tencent/slide-sdk-model / @tencent/slide-sdk-pb-model（腾讯文档私有 protobuf 模型），由 slidep 依赖；周边工具则包括 markitdown、python-pptx、pptx2image.py 等通用脚本。

这种"通用核心 + 领域插件"的分层，与 Anthropic 把 Skill 视为"可编码的领域知识与工作流"的思路一致，也是当前大模型 Agent 平台的主流做法。

编排方式对比：DAG vs 通用循环 + Skill

这里有一个容易误解的点：在用户能感知到的聊天入口里，这些平台的"流程"并不像 Dify、n8n 那样，被画成一张可见的有向无环图（DAG）。

在 DAG 路线里，节点和连线是写死的，A 节点输出固定流向 B 节点。在通用 Agent Loop 路线里，流程由循环动态读取 Skill 的 markdown 指令来执行。

但这不等于平台内部"没有 DAG"。公开架构文档显示，WorkBuddy 内部也存在一套基于 DAG 的工作流引擎，按依赖关系调度步骤并持久化运行；它只是藏在聊天入口背后，普通用户感知不到（可见的画布编辑器不在本文讨论范围）。

两种路线各有适用场景：DAG 适合流程稳定、审批明确的业务；通用循环 + Skill 更适合需要 LLM 动态决策、步骤可变的任务。办公 Agent 之所以更突出后者，正因为用户随口说出的意图往往不够结构化。

所以更准确的说法是：用户可感知的是"通用循环 + Skill SOP"这一层抽象，而平台内部常常是"循环 + DAG 引擎"的混合体。

这不是说没有结构，而是结构以"Skill SOP"的形式存在：需求澄清 → STORY → DESIGN → 逐页 lint → upsert-dsl。循环按 SOP 推进，而不是按死板的图推进。

上图里，用户只站在①层；②层的 DAG 引擎由平台自动调度，普通用户在聊天入口感知不到，可见的画布编辑器也不在讨论范围。

迁移的暗坑：大脑好搬，手难移

同样的分层，也解释了为什么迁移难度天差地别。

技能包（大脑）本质上是文本、提示词、规范。只要协议兼容，迁移相对容易。

但工具包（手）如果深度绑定腾讯文档云 SDK——例如 @tencent/docs-slide-view-sdk-node、cos-nodejs-sdk-v5 等——一旦脱离原有环境，模板、渲染、云存储链路就会断裂。换平台时，常常是"脑"过去了，"手"还在原地。

这也是为什么开源社区在复刻某个办公 Agent 能力时，能较快对齐提示词和规范，却很难直接复用它的执行引擎。引擎层的云依赖，是最真实的壁垒。

一个新概念：Skill 程序化 SOP Agent

基于上面的观察，可以把这种架构叫做 Skill 程序化 SOP Agent。

通用 Agent Loop 提供推理与执行框架；Skill 把某个领域的标准操作流程（SOP）编码成机器可读的指令：做什么、调用什么工具、输出什么格式、如何检查质量。

它本质上是在回答一个问题：当 LLM 拿到一个任务后，应该按照什么顺序调用哪些工具、遵循哪些约束。SOP 不再写在手册里，而是写进 Skill 文件里。

无数个这样的 Skill SOP 窄 Agent，共同运行在同一个通用 Loop 之上。平台的丰富程度，取决于这个循环的健壮程度，以及 Skill 库的深度。

写在最后

所以，豆包工作、TRAE、WorkBuddy 这类产品的本质，不是"一个能做很多事的 Agent"，而是一个通用 Agent Loop 加上无数 Skill 程序化 SOP 的具象化。

做 PPT 和写代码，共享同一套循环；它们的区别只在于加载了不同的 Skill、引擎和格式。做表格与做海报之间，差异也不是"有没有 Agent"，而是"加载了哪一套 Skill SOP"。

理解了这一点，再看"Agent 平台"就不会只盯着入口，而是能看到循环、Skill、引擎三者之间的真实边界。下一步选型或自研时，也可以按这三层逐一评估，而不是被一个大而全的概念牵着走。

一个值得讨论的问题：在你看来，未来 Agent 平台会更像 Dify 的 DAG 工作流，还是更像 Skill 驱动的通用循环？欢迎在评论区留下你的判断，点个「在看」或「收藏」，方便后续一起聊透智能体编排这件事。

【欢迎访问我的https://wisdomlog.sheepread.online，这里有我的精选文章和AI大模型日报专栏。👇）

#智能体编排 #AgentLoop #Skill #SOP #办公Agent #大模型应用 #WorkBuddy