AI 工程实践

从课程智能体到标准化 Agent 工作流：一次模板化复盘

把一次课程智能体实践抽象成可复用模板的复盘：为什么知识库边界、行为协议、发布清单、回归测试和维护记录，比单次 prompt 调优更重要。

背景

最开始的问题很具体：如何为一门课程或一组资料做一个可靠的智能体，让它能回答学生的常见问题，同时不要越界、不要编造、不要把没有依据的信息说得像事实。

如果只看第一版实现，这似乎是一个 prompt 和知识库上传问题。但真正做下去后，核心问题很快变成了工程问题：资料怎么整理，哪些文件能进知识库，哪些只能给维护者看，系统提示词如何和资料保持一致，发布前怎么验证，资料更新后如何确认旧问题没有退化。

所以我把这次实践抽象成了一个独立仓库：Standardized Agent Workflow。它的目标不是提供某个单一智能体，而是提供一套可以复用的建设流程。

智能体项目很容易从一个漂亮 prompt 开始，也很容易被漂亮 prompt 限制住。Prompt 能定义角色和风格，但它不能单独解决这些问题：

这些问题更像软件工程里的接口、测试、发布和维护，而不是单次生成效果。因此我选择把项目拆成知识库、行为协议、检查清单、测试问题和维护记录几层。

这套工作流来自一个具体智能体，但最终抽象成三层：

特定智能体
  解决一个明确场景，例如某门课程、某个团队流程、某类业务资料。

通用领域智能体
  抽出领域内通用结构，例如所有课程都需要课程事实、资料边界、学术诚信、测试问题。

通用智能体工作流
  抽出所有 RAG/知识库智能体共有的工程流程：资料治理、行为边界、发布同步、测试和维护。

这个抽象让我不再只问“这个智能体怎么答得更好”，而是问“下一个智能体能不能更快、更稳、更可交接地搭起来”。

很多知识库型智能体的问题，根源不是模型不够聪明，而是资料边界不清。模板要求一开始就把资料分成三类：

用户可见资料进入 knowledge_base/；维护者资料留在 maintenance/、examples/、_templates/ 和 _manifests/；隐私、个人作品、内部敏感资料不进入任何用户知识库。

这个步骤看起来朴素，但它决定了智能体的可信边界。一个 agent 应该知道什么，不该知道什么，应该从资料治理阶段就被确定下来。

把文件上传进知识库不等于知识库设计完成。真正可用的知识库需要让检索更容易命中，让高风险事实更容易核验，让维护者更容易更新。

所以模板提供了几类结构：

这套结构的意义是让资料从“能被存放”变成“能被检索、能被引用、能被维护”。

另一个容易被低估的部分是 agent 行为协议。维护者通常会在心里知道“这个问题不能答”“这个场景要保守”“没有资料时要说不知道”，但如果这些规则没有写进系统提示词、回答策略和意图映射，就很难稳定复现。

模板把这些内容放在 agent/ 目录中：

这样做还有一个好处：当知识库迁移到不同平台时，行为协议可以跟着走，而不是被锁在某个平台的配置界面里。

智能体项目一旦上线，最危险的不是第一次回答错，而是更新后没人知道它哪里退化了。模板要求维护者准备核心回归问题，覆盖：

每次发布或资料更新后，都要运行这些问题，并把结果写入测试记录。这个动作把“感觉它还不错”变成“这个版本通过了哪些验证”。

RAG 项目还有一个常见问题：本地文件改了，但线上知识库到底有没有更新，没人能说清楚。为了解决这个问题，模板要求维护者维护上传清单。

上传清单要回答几个问题：

这让发布从一次手工操作变成一个可以复查的流程。未来换维护者、换平台或回溯问题时，项目不会只剩一堆文件和模糊记忆。

把这套流程抽成模板后，它可以服务更多场景：

这些场景表面不同，但底层都需要资料边界、事实来源、行为协议、发布同步、回归测试和维护记录。模板的价值就在于把这些共性提前铺好。

这次抽象让我对智能体项目有了一个更稳定的判断：智能体不是越会编越好，而是越有依据、越有边界、越可验证越好。

真正能长期运行的 agent，不只需要一个好 prompt，还需要一套让维护者能看懂、能更新、能测试、能迁移的工程流程。