夜雨聆风
序言：别把 Agent 做成一场技术表演
教程定位
这两年我一直在做 .NET + AI 相关的教程研发。
最早是 Semantic Kernel 从入门到精通。
那门教程更像是框架入门教程：带大家理解 Semantic Kernel 的基本概念、插件机制、Prompt、Planner、Memory，以及怎么用 .NET 把这些能力串起来。
后来我又做了 .NET + AI｜Agent 开发进阶。
那一阶段，重点已经从“怎么调用模型”往前走了一步，开始讲 Agent、工具调用、Skills、Microsoft Agent Framework、IChatClient、工作流和一些更接近真实应用的开发方式。
这些教程都有价值。
但做完以后，我越来越明显地发现一个问题：
很多同学学会了框架，也能跑通示例，却依然不知道怎么真正开发一个 Agent 产品。
他们知道 Prompt 怎么写。
知道 Function Calling 怎么接。
知道 Agent Framework 里有哪些概念。
也能照着示例做出一个 Demo。
但一旦离开教程样例，开始做自己的产品，就会很快卡住：
第一个功能不知道该切多小 Agent 职责越写越乱 工具和业务逻辑边界不清 前端交互不知道怎么承接 Agent 输出 AI Coding 写得很快，但项目越来越难维护 Demo 能跑，继续往产品走却很吃力
这时候我意识到：
前面的教程更多解决的是“框架怎么用”。
但很多人真正缺的不是框架知识。
而是：
如何把一个 Agent Demo，持续演进成一个真正可用、可维护、可扩展的产品。
这就是这门教程的起点。
所以这节序言不急着讲具体代码，也不急着讲某个框架 API。
它先要把整门教程的基调定下来：
我们不只学“怎么把 Agent 跑起来”。
我们更要学“怎么把 Agent 做下去”。
一、为什么我不想把这门教程讲成“框架教程”
市面上已经有很多教程在讲 AI 应用和 Agent 开发里的单点能力：
提示工程怎么写 RAG 怎么搭 Vibe Coding 怎么用 MCP 怎么接 Agent Skills 怎么组织 Harness 怎么理解 多 Agent 怎么编排 某个 Agent Framework 怎么快速上手
这些内容都很有价值。
它们解决的是“某个能力怎么用”的问题。
比如 Prompt 解决表达问题，RAG 解决知识接入问题，MCP 解决工具生态问题，Skills 解决能力复用问题，Harness 解决执行控制问题，Vibe Coding 解决快速探索问题。
但一个 Agent 产品真正做起来以后，你很快会发现：
会用这些能力，不等于知道什么时候该用、用到什么程度、以及什么时候该忍住不用。
这些内容教程里也会涉及。
但如果只讲这些，这门教程就会变成另一套“技术点串讲”。
你学完以后，可能知道了很多概念，却仍然不知道：
第一个功能到底该做多小？ 什么时候应该加第二个 Agent？ 什么时候该抽象？ 什么时候该忍住不抽象？ AI Coding 什么时候能帮忙，什么时候反而会添乱？ 为什么 Demo 很顺，产品化却越做越累？
这些问题，才是 Agent 产品真正会卡住你的地方。
所以这门教程不会只围绕“某个框架怎么用”展开。
它会围绕一个更实际的问题展开：
如何从 0 到 1，持续推进一个 Agent 产品，而不是只做出一个漂亮演示。
框架只是工具。
模型只是工具。
AI Coding 也是工具。
真正决定项目能不能往前走的，是你怎么控制边界、节奏和复杂度。
二、AI WritingFlow 不是标准答案，而是一份踩坑样本
这门教程会基于 AI WritingFlow 的真实开发过程展开。
但我不想把它包装成一个“最佳实践项目”。
更准确地说，它是一份踩坑样本。
AI WritingFlow 一开始的想法很大：
选题澄清 调研发现 大纲生成 初稿写作 润色改写 去 AI 味 文章配图 封面生成 图片卡片 信息图 发布包装
听起来很完整。
也很诱人。
但完整的想法，并不等于正确的起点。
我在这个项目里走过不少弯路：
一开始容易把写作流程想成固定流水线 容易过早设计多 Agent 分工 容易把 Workflow、Harness、Orchestration 混在一起 容易让运行时机制夹带某个阶段的特判 容易把用户记忆设计成复杂画像系统 容易让 AI 一次性生成太多还没被验证的代码 容易把“看起来高级”的架构当成真实进展
这些弯路不是个别问题。
它们几乎是所有 Agent 产品都会遇到的问题。
因为 Agent 项目天然会诱惑你做大。
模型能写。
工具能接。
前端能生成。
多 Agent 能编排。
Memory 能加。
Workflow 能画。
MCP 能扩展。
于是你很容易产生一种错觉：
既然 AI 能帮我做，那我就先把系统做完整一点。
但很多时候，真正拖慢你的，恰恰是这个“完整一点”。
三、这门教程的基调：真实、克制、能持续推进
这门教程的基调不是炫技。
也不是制造焦虑。
更不是告诉你“只要用了某个框架，就能快速做出 Agent 产品”。
这门教程想建立的是三种手感。
1. 真实感
真实的 Agent 产品开发，不是一路顺风。
它通常是这样的：
先做了一个能跑的版本 然后发现产品边界不对 再改 Agent 的职责 再改前端交互 再改状态存储 再改运行时目录 再改 prompt 和工具边界 再补测试、补约束、补文档
这个过程里会有返工。
会有推倒重来。
也会有很多“早知道就不该这么做”。
这不是失败。
这是产品从想法变成系统的正常过程。
2. 克制感
Agent 开发最缺的往往不是能力，而是克制。
你会不断遇到这些选择：
要不要现在上多 Agent？ 要不要现在做完整工作流？ 要不要现在接 MCP？ 要不要现在做权限？ 要不要现在做计费？ 要不要现在抽象一套配置系统？
很多东西不是不能做。
而是现在不该做。
这门教程会不断强调一个原则：
先做闭环，再做扩张。先验证真实需求，再设计长期结构。
3. 可持续推进感
Agent 产品不是拼谁第一天冲得猛。
而是拼谁能连续推进一个月、三个月、半年，项目还没有失控。
所以我们不会只追求“今天 AI 帮我写了多少代码”。
我们更关心：
这段代码后面还能不能改？ 这个 Agent 的职责是否清楚？ 这个工具边界是否稳定？ 这个状态是否可解释？ 这个抽象是否真的来自重复模式？ 这个上下文是否会把 AI 带偏？
这些问题看起来慢。
但长期看，它们才是快。
四、这门教程不是反对 AI Coding，而是反对失控地用 AI Coding
我非常依赖 AI Coding。
这门教程本身也离不开 AI Coding。
Claude、Codex、Cursor、GitHub Copilot、Gemini，都可以成为开发过程中的重要助手。
但我越来越强烈地感受到一件事：
AI Coding 不是越早放开越好，而是越早管住越好。
如果你在产品边界还不清楚的时候，就让 AI 大规模写业务代码，它会很认真地帮你把混乱扩大。
它会生成很多看起来合理的目录。
很多看起来专业的接口。
很多看起来完整的抽象。
很多看起来可扩展的配置。
但这些东西可能并没有经过真实需求验证。
所以教程中我们会把 AI Coding 分成几个阶段来看：
- 探索阶段
：让 AI 帮你发散、追问、发现盲点。 - 骨架阶段
：让 AI 帮你建立清晰项目结构和约束。 - 闭环阶段
：让 AI 帮你完成最小可运行路径。 - 扩张阶段
：当模式出现后，再让 AI 批量生成相似 Agent、页面和工具。 - 工程化阶段
：让 AI 辅助补测试、文档、质量门禁、监控和成本控制。
顺序很重要。
如果一开始就跳到第 4 步，AI 会变得很快。
项目也会很快变乱。
五、这门教程会反复围绕四条主线展开
整门教程看起来有 16 个主线教程时，加 1 个加餐专题。
但底层其实只有四条主线。
第一条：先做闭环，再做扩张
不要从完整平台开始。
先从一个用户输入，到一个可见结果，到一次用户选择开始。
对 AI WritingFlow 来说，第一步不是完整写作平台。
而是：
用户输入一个模糊想法，Agent 帮他澄清，并给出几个可继续展开的选题方向。
这就够小。
也够真实。
第二条：先建立边界，再优化效率
Agent 的边界不清，后面所有效率都会变成负担。
所以我们会不断区分：
Agent 做什么，不做什么 Tool 做什么，不做什么 Skill 做什么，不做什么 前端负责什么，后端负责什么 运行时记忆、正式工件、用户长期记忆分别放哪里
边界清楚以后，AI 才能稳定协作。
第三条：先管住 AI，再放大 AI
AI 很强。
但它需要规则。
需要 agents.md。
需要项目结构。
需要 Skills。
需要验证命令。
需要明确哪些文件可以改，哪些架构边界不能碰。
没有这些约束，AI 写得越多，风险越大。
第四条：先做能持续推进的系统，再做看起来高级的系统
MCP、Workflow、A2A、Harness、多 Agent、Memory、Telemetry 都重要。
但它们不应该成为 Day 1 的负担。
教程会强调：
不是不用高级能力，而是等问题真的需要它时再引入。
这也是 Agent 产品工程化最重要的判断力。
六、你应该怎样学习这门教程
这门教程不适合只当成视频或文章看一遍。
更适合边看边做。
每一讲都可以问自己三个问题。
1. 我自己的 Agent 产品里，有没有同样的问题？
比如第一讲讲最小闭环。
你就不要只记住“要做 MVP”。
而是要写下来：
我的产品里，用户第一个动作是什么？第一个可见结果是什么？第一版明确不做什么？
2. 我现在是不是太早做了某件事？
看到多 Agent，就问自己：
我真的已经需要多个 Agent，还是一个 Agent 加工具就够了？
看到 Memory，就问自己：
我真的需要复杂记忆系统，还是先用一个可读的用户偏好文件就够了？
看到 Workflow，就问自己：
我真的需要工作流引擎，还是只是需要一个清楚的页面步骤？
3. 我能不能把本教程结论落成一个小动作？
不要老是想着“大重构”。
更好的学习方式是每讲做一个小动作：
写一句产品定义 删掉 3 个第一版不做的功能 把一个 Agent 的职责写清楚 给一个工具补上输入输出边界 写一条 agents.md 约束 给一个关键路径补一个测试
Agent 产品就是这样一点点从混乱里长出来的。
七、适合谁，不适合谁
这个教程适合这些人：
已经会一点 .NET 或愿意用 .NET 做 AI 应用的人 想从 Agent Demo 走向真实产品的人 正在用 Claude、Codex、Cursor、Copilot 做 AI Coding 的人 做过 Demo，但感觉产品化很吃力的人 想建立长期 Agent 工程能力的人
这门教程不太适合这些人：
只想复制一份完整代码，不关心为什么这么设计 只想追最新框架名词，不关心产品边界 希望 AI 一次性把产品全部做完 不愿意接受返工和迭代
如果你想要的是一个神奇公式：
用某某框架 + 某某模型 = 自动得到 Agent 产品
那这个系列不会给你这个答案。
如果你想要的是一套能长期推进项目的方法，那它会更适合你。
八、序言小结
我想定下的基调很简单：
做 Agent，不是一场漂亮的技术表演。
它更像是一场长期拉扯。
你一边借 AI 的力。
一边又得不断约束 AI。
一边想快。
一边又得忍住不乱。
一边想做大。
一边又得逼自己从最小闭环开始。
如果整门教程最后只留下一个感觉，我希望是这个：
既敢用 AI，又不迷信 AI。既追求效率，又保持工程克制。
从下一篇文章开始，我们会进入第一个具体问题：
想法很大，起点很低，没关系。
先不急着写代码。
先把起点压低。
因为只有起点足够低，产品才真的有机会开始。
学前思考
在开始开发 Agent 前，请先写下 5 个答案：
你想做的 Agent 产品，一句话是什么？ 如果只允许做一天，你会先做哪个闭环？ 这个闭环的用户输入是什么？ 这个闭环的可见输出是什么？ 第一版你明确不做哪 5 件事？
如果这些问题暂时答不清楚，没关系。
这正是我接下来要带你解决的问题。
