夜雨聆风
这个视频内容很实在和工程实践相符，在喧嚣的时代没有实事求是能够帮助你排除噪音更可贵的，建议深度阅读。
加拿大一家 CRM 平台找到 Towards AI，需要一个 Multi-Agent 系统，原因是他们正申请一笔 AI 资助，需要一个 AI Native 的产品来匹配。他们的需求很简单，让用户能够一键生成营销内容。Towards AI 的 CTO Louis-François Bouchard 和他们一起拆解流程，整个流程只需要四步，制定计划、检索客户数据、生成内容、校验和修正，并且四步永远是同样的顺序。
最后他们只搭了一个 Agent。但把验证、SMS 格式、email 格式做成独立 Tools，每个 Tool 有自己的 System Prompt、自己的校验逻辑、甚至可以自己调用 LLM。唯一的 Agent 拥有全局上下文，这个 Agent 同时是 Planner 和决策者。
这是 AI Engineer 大会上一场两小时 workshop 的开头片段。三个讲者常年做 AI 工程教育。Louis 在 ChatGPT 出来之前是 Mila 的 AI 博士生，做了七年论文讲解视频。Paul Iusztin 写过畅销书《LLM Engineer's Handbook》，做过自动驾驶感知、零售视觉、再到金融 Agent，十年软件工程的密度。Samridhi 是 Towards AI 的机器学习工程师，负责把整套系统的代码跑起来。三个人合起来做了一套"一键把主题变成可发布技术文章"的系统，又反过来用这套系统做了一门课，教别人怎么搭建这套系统。
他们想回答的是 AI 工程师的判断力到底应该放在哪里。
判断什么时候不上 Agent
Louis 开场先画了一条关于系统自主性的滑杆。最左端是简单的 Prompt，最右端是完整的 Agentic 系统。越往右走，系统自主性越高，你对它的控制力就越弱，成本也越高。他们给客户做项目时的一条经验是，永远先用最简单的方案，能 Prompt 解决就别搭 Workflow，能 Workflow 解决就别搭 Agent。
那 Agent 的边界在哪里？Louis 沿用了 Anthropic 的一句定义，当系统需要采取行动、并且能对环境里发生的事情做出反应时，它才叫 Agent。能判断该用哪个工具，更重要是能判断不该用哪个工具。
反例也很具体。一个客服工单系统的流程永远是收工单、分类、路由、起草回复、按策略校验、发送，六步顺序一成不变。把这个做成 Agent 只会徒增开销，没有任何收益。什么时候才真的需要 Agent？当系统必须动态分支的时候，比如要调不同 API、要写数据库、要看情况跳过某一步。CRM 那个营销内容 chatbot 看起来该做成 Agent，但拆开后发现是四步固定的事，全程依赖同一份上下文，所以做成了单 Agent 加专家 Tools 的结构，没有走 Multi-Agent 路线。
但这种克制带来一条反直觉的工程约束，当所有东西都压在一个 Agent 里，又会撞上「Context Rot」的天花板。
Context Rot 的真实阈值是 200k
模型厂商宣传的上下文窗口是一百万 Token，Louis 在现场给的观察是，性能衰退远在 1M 之前就开始了，大约超过 200k 就迅速恶化。
原因来自 Long-Context 模型的训练方式，喂一大段语料、中间塞一个随机事实、让模型检索那个事实。这训的是"从一大堆里挑出一个具体片段"的能力，但不具备综合整本书来回答问题的能力。要训后者，数据集做起来太贵。
结果就是每个 AI 工程师实际上都在管理一份 Context Budget。手段是裁剪、摘要、按条件检索，Claude Code 代码泄露出来的一批 Compaction 技巧也值得翻一翻。但 Louis 最看好的方向是 Delegation，把活交给独立上下文的 Sub-Agents，这也是现在主流 Agent Harness 的做法。
什么时候应该上 Multi-Agent 也就明确起来。工具数超过 20 个、上下文被撑爆、真正需要自主决策、或者有合规隔离要求（比如医院里 Agent 必须本地部署）。除此之外的 Multi-Agent 需求，多数是把简单问题搞复杂。
两个 Agent 不搞编排，只共享文件
回到他们自己的 Deep Research 系统。Louis 做的第一个决策是把整件事拆成两个彻底独立的系统，一个 Research Agent 负责探索、迭代、在网上搜到满意为止，一个 Writer 负责把研究结果写成技术文章。原因很直接，研究需要 flexibility，写作需要 constraint。写作靠自由发挥会跑出 AI 腔，研究用固定步骤又会被卡住。
接下来是两个 Agent 怎么通信。团队实际使用时发现一个规律，要么两个 Agent 都用，要么都不用。几乎没有人在两者之间来回切。真要切，也只是最后让 Writer 加一点新建议或者删几段。一旦要大改，干脆整条流水线重跑一遍。
所以他们给出的决定是顺序跑，不搞编排层。一个很简单的脚本，两个 Agent 共享一份 research.md 文件。两个 Agent 放同一个项目，既好维护，又对 Claude Code 这类 AI 辅助编程工具特别友好，这样的目录布局让 AI 辅助工具能同时看懂两边的代码。
Guideline 这一部分值得学习。Guideline 由人手写，格式包含主题是什么、这节课想覆盖什么、人工推荐的几个 source 链接。Louis 反复强调的一句话是，"我们越把 Agent 的目标定得细、给它的自由越少，结果越好"。这是他们做完几百份课程之后得出的结论。
写文章这件事，根本不需要 Agent
交接到 Paul 之后，他直接说，写内容根本不需要 Agent，不管是 LinkedIn 帖子、视频、文章还是课程讲义。流程非常静态，每次走的都是同样的步骤。塞 Agent 进来只会把事情搞复杂。
他们的 Writing Workflow 分成三段，加载 Context、调 LLM 出初稿、跑 Evaluator-Optimizer 循环。Context 这一段有三个具体手法值得看。
第一个手法是把 Guideline 结构化。Guideline 要写清楚 angle、target audience、key points、tone、character 约束，"给我写一篇 X 主题的帖子"这种笼统问法不够用。这也是整个系统里每次需要手写的唯一部分。Paul 在 demo 里展示了一份真实 Guideline 文件，五个字段加起来几十行文字。如果你不愿花这点力气，产出就是 slop。
第二个手法是三份静态 Writing Profile，都是 Markdown 文件。Structure Profile 写 LinkedIn 帖子的长度和 hook / body / CTA 结构。Terminology Profile 维护一份 AI slop 词的黑名单（delve、tapestry、vibrant 这类）。Character Profile 配讲者自己的传记和风格。Paul 对黑名单的措辞是，你只能维护一份超长名单，然后客客气气地请求 LLM 别用这些词，直到你自己开始像人类一样用它们为止。
第三个手法是 Few-shot examples。Paul 放了 3 条他自己 traction 最好的 LinkedIn 帖子。为什么是 3？他说"3 是玄学，老实说是猜的"。原则是在能做对事的前提下尽可能少。他的方法是从大数字往下砍，砍到不 work 为止再补一条回去。原因是 Few-shot 永远在 System Prompt 里，Token 越多越贵、越慢，还会因为 Context 膨胀导致性能下滑。
Reviewer 跑在独立上下文里
Evaluator-Optimizer 的做法值得拆开看。它跑两次 LLM 调用，但运行在两个完全独立的上下文窗口里，一个是 Writer，另一个是 Reviewer。Writer 写完初稿，Reviewer 在一个全新的上下文里拿到这份稿子做审校。
Paul 给出的原因是，LLM 天然偏爱自己写的东西，扔到新上下文里重新审，就能去掉这个偏见。
Reviewer 检查三件事，优先级依次是 Guideline、Research、Profile，冲突时按这个排序取舍。Reviewer 的输出是一组 Pydantic 结构化对象，每个对象有 Profile、location、comment 三个字段，每个字段都配一段说明告诉 LLM 这里该填什么。这是一种 Prompt Engineering 手法，效果远强于让 LLM 随便写。
loop 的终止条件是另一个值得看的决定。常见做法是 Reviewer 打分、跑到达到阈值为止，Paul 没使用这个方法。他的说法是，创造性工作是主观的，阈值很难量化，这个 loop 会噪音很大，很不可靠，直接写死跑 3 到 4 轮反而更稳。
还有一个产品设计上的细节，所有 draft 版本都保留在工作目录里。因为 Reviewer 太激进反而会把人不喜欢的东西改进来，你得能回过去挑最满意的那一版。AI 内容工具普遍只给最终产出，"给你 v0 到 v4 自己挑"反而是低成本、高差异的产品选择。
评估 LLM Judge 本身才是最重要的一步
最后一部分是 AI Evals。
典型失控过程是这样的。生成一条你读一下说还行，生成 10 条你读两三条凑合，到 100 条你根本不可能靠眼睛看。更严重的是，每加一个新 feature 都可能把老功能搞坏。你用的是 Prompt，某个地方多出一个词就能让整套东西崩掉。
所以 Evals 要建一个数据集，然后在上面训一个 LLM Judge。Paul 的具体做法里有两条铁律。
第一条，永远不要让 LLM 直接生成 Output。做合成数据时可以让 LLM 帮你生成 Input，但 Output 必须来自你真实系统，因为你测的就是这个系统。他从自己 LinkedIn 抽了 20 条真实帖子，反向工程出 Guideline，再用真实的 Deep Research Agent 跑出 Research，最后让真实 Writing Workflow 生成新帖子。然后人工逐条打 pass / fail 和两三句 critique。这条铁律常被合成数据实践忽视，很多团队让 LLM 生成 Input 和 Output 一起来，测出来的永远是 Judge 和 Data Generator 之间的自我循环。
第二条，一定要评估 Judge 本身。这一步被大多数做 LLM-as-Judge 的团队直接跳过，但 Paul 说它恰恰是最重要的一步。Judge 本质是个二元分类器，按训分类器的流程走，dev split 跑 Judge 算 F1，调 Prompt 和 Few-shot 把 F1 拉满，最后在 test split 上做终验。判断过拟合靠的是 dev 和 test F1 的差值，dev 高加上 test 低就是过拟合。绝对数字反而只反映数据分布。
Paul 最后跑了一段 demo。他在模拟的线上 Trace 上跑自己校准过的 LLM Judge，结果 Judge 对所有 Trace 都打了 pass，但他手里的标注显示其中几条应该 fail。他直接说，这个系统还没完美，他得回到 dev split，把这些样本补进去，继续迭代。在技术大会上公开展示自己的 Judge 还不够好，然后告诉你怎么继续改。
读完能带走什么
做 Agent 系统，先问"是不是 Workflow 就够"再往下走。做 RAG 和多轮，把 200k 当作 Context 的性能拐点，别跟着 1M 的宣传走。做 AI 内容产品，明确承认写作不需要 Agent，用 Workflow 加三份静态 Profile 加结构化 Guideline 就能把 slop 压下去。做合成数据，记住 Output 必须来自真实系统，别让 LLM 替你写 ground truth。做 Eval，评估 Judge 本身比调 Judge Prompt 更重要。
这整场 workshop 真正稀缺的是一种判断力。知道什么时候一个 Agent 就够、什么时候两个 Agent 都多余、什么时候一份人手写的 Guideline 比十轮 reasoning 更靠谱。
内容来源，AI Engineer 频道「Full Workshop: Build Your Own Deep Research Agents」，YouTube 链接 https://youtu.be/mYSRn6PC1mc
