【极客时间】AI业务流架构师训练营

这套训练营的主题不是「调一个更聪明的提示词」，而是把 Agent 当成一个需要长期维护的工程系统来做。它讨论的是 AI 业务流的架构问题：多个数字员工如何分工、配置如何组织、价值观与行为边界写在哪里、跨平台落地时哪些层可以复用。如果你已经在用 API 拼过几个自动化脚本，但发现越往后越乱——提示词散落各处、行为漂移、换个平台就要重写——那这套资料的对照价值会比较直接。

它解决的是「工程结构」而不是「模型能力」

课程里有一条很明确的主线：把 Agent 的「灵魂」从代码里抽出来，放到纯文本配置中去管理。以 SOUL.md 为载体的做法，本质上是给 Agent 定义一份可版本控制、可 diff、可评审的行为契约——价值观、身份、不可变内核都写在里面，模型换、平台换，这份契约仍然成立。这跟传统的 prompt engineering 有区别：后者关注的是一次对话的效果，前者关注的是这套配置在几十次迭代、多个场景之后还能不能保持一致。

配套的 Workspace 配置体系是另一个值得对照的点。它把 Agent 运行所需的各类配置文件拆成有明确职责的若干份，而不是塞进一个巨大的 JSON。这种拆分方式在单个 Agent 上可能显得啰嗦，但一旦你要同时维护研发助手、客服助手、数据分析助手，配置的复用和覆盖关系就变成必须提前设计的东西。

Markdown 调教法：把约束写成可读文档

资料包中权重较大的一部分是「Markdown 调教法」。它的思路是：Agent 的行为规则、禁止事项、输出格式、异常处理策略，都用结构化的 Markdown 描述，而不是散在代码注释或系统提示里。好处有三层——人能读，评审时能看出边界在哪；模型能读，长上下文下结构比自由文本更稳；工具能读，构建流程里可以直接做校验和注入。

对应到实践，这套方法适合拿来整理你现有的提示词资产。大多数人的 Agent 项目到中期都会出现「规则打补丁」的问题，Markdown 化的价值就是让补丁有地方放，并且有层级关系。

研发助手作为贯穿案例

课程用「铸造研发助手灵魂」作为一个完整的实战切片，从纯文本驱动的设计哲学讲起，再到 SOUL.md 的逐层拆解，最后落到一个可运行的助手。选研发助手做案例有它的道理：这个场景对上下文理解、工具调用、输出规范的要求都比较高，能暴露配置设计里的问题。你如果做的是客服、运营或数据分析类 Agent，结构上的迁移成本不高，把领域知识替换掉即可。

怎么用这份资料

• 先看配置体系的整体设计，理解各文件的职责划分，再动手写自己的第一版，不要一开始就照搬全部字段。
• 把 SOUL.md 当成一个需要迭代的产物，每遇到一次行为偏差就回填一条规则，几轮之后你会得到一份真正贴合业务的契约。
• 跨平台案例部分建议对照自己当前的技术栈看，重点不在复制代码，而在看它如何隔离平台差异层。
• 视频适合在写过一版配置之后再看，先有具体问题，讲解才落得下去。

整体上，这套内容更适合已经动手做过 Agent、需要把项目从「能跑」推到「能维护」的开发者。纯新手直接看配置分层可能会觉得抽象，建议先自己用 API 写一个带工具调用的助手，再回来对照。