做智能体的人多半撞过同一堵墙：v0 版本在评测里跑得不错，迁到新模型就翻车；或者新场景从零搭，原型跑通，发布就崩。Anthropic 伦敦应用 AI 工程师 Margot Van Laar 在 Code with Claude 开发者大会的分会场里，用一个真实风格的客服机器人例子和一段零售排班智能体例子，把这两类日常场景里最常见的坑点过了一遍。
这场分享是当天最后一场，全长三十三分二十四秒；视频原帖由 X 账号 @RahulTechX（运营者 Rahul Kumar）发布。演讲者身份以视频自我介绍为准：My name is Margot Van Laar，I am an applied AI engineer at Anthropic here in London。本文事实只取自这场分享，方法按两类工作场景展开——迁移现有提示词到新模型、从零构建全新智能体。全文带走九样东西：1 套先评估再动手的纪律、3 类必备测试用例、1 套通用卫生清理清单、3 个失败模式与各自修法、1 个从零构建的智能体案例、5 种方案对比、3 段独立 prompt 拆解、1 段综合方法论，外加 1 条使用边界。
01 迁移前先建评估：两种下降原因，要分清
迁移到新模型后效果下降，常见原因有二。一种是模型能力够，但行为不同——比如新版本更听指令，旧版本的某些兜底话术变成了过度执行，这种可以通过调提示词修。另一种是模型本身能力不够，调提示词怎么也救不回来。区分这两件事只有一种办法：评估套件。
评估的定位是回归测试的基线——任何提示词调整都跑一次评估，看分数是涨是跌。这套纪律有几条暗含的硬约束：评估用例要稳定、答案要可机械判定、不能只看平均分；先建评估再动提示词，顺序不能颠倒；评估要能区分"模型听话了但说错"与"模型没听懂"两种失败，否则改提示词时容易盲目试错。
讲者原话是这么说的：we need evaluations to provide that rigor, to understand whether a change to our prompt is actually correlating to an improvement in its performance。在她展示的演示环境里，五条测试用例一次跑完，五个结果分项打分，一目了然。
02 三类测试用例：对照、边缘、能力边界
评估建好之后，用例怎么挑？她给的三类划分足够覆盖大多数客服与流程场景。
第一类是对照用例，模型理应稳定通过、毫无歧义、历史上一直表现良好。它是基线——一旦对照用例挂掉，说明改动动了不该动的地方，要立刻回滚。
第二类是边缘用例，历史上模型曾失败过、在提示词里加指令防复发的场景。边缘用例的复盘价值最高，每条都对应一次事故，复盘时把当时为什么挂、后来怎么救的写清楚。
第三类是能力边界用例，模型需要清楚自己能力的边界：什么时候该转人工、什么时候该直接拒答。这一类不是问模型会不会做，而是问模型知不知道什么时候不该做。
她强调，第三类最容易被忽略——团队容易盯着前两类反复调，反而把"拒答"和"升级"这种安全阀做得很薄，结果在生产里把幻觉问题换成了一线员工兜底所有边界。
03 Meridian Mobile：5 个测试用例，串起一个客服机器人
例子是一家虚构电信公司 Meridian Mobile 的客服机器人。评估套件里放了五条用例：
- 基础套餐流量限额——对照用例，无歧义，模型应当稳定通过。
- 按比例计费——边缘用例，考验客户在月中切套餐或账单周期时，模型能否正确换算。
- 政策关键问题——边缘用例，对应"政策文档怎么用、用哪一条"。
- 检测到账单错误时升级人工——能力边界用例，模型必须主动转交。
- 不隐瞒应告知客户的信息——能力边界用例，对应"不能扣住已知信息"。
流程是这样的：先用初版提示词跑一遍 v0 评估，观察失败模式；逐个系统性地针对每条失败模式调整提示词；每改一次再跑一次评估，盯紧分项打分。她把这一步叫做 iterate the prompt for each failure mode——不是一上来就大改，而是锁定一个失败模式，改一段，再跑，再锁下一个。
04 通用卫生清理：在动失败模式之前，先把提示词"打扫干净"
锁定失败模式之前，先做一轮提示词的通用卫生清理——她把这步叫做 general hygiene。清理动作有四件：
- 删除冗余信息。比如从网页复制过来的 hero image 描述、cookies 通知，这些对模型理解任务毫无帮助。
- 把指令拆成分层结构，用 XML 标签分隔角色、通用指南、政策、语气等。提示词里塞成一坨的，模型同样分不清。
- 建立输出契约，定义输出格式，要求模型用 XML 标签包裹响应，或者直接上 structured outputs。
- 在 API 调用里加 stop sequence，检测收尾的 XML 标签以保证一致性。
她给了一条经验准则：if a human can't distinguish guidelines from policy from data in the prompt, neither can the model。人读起来一团浆糊，模型读起来更是一团浆糊——这一点和代码 review 的味道很像，可读性差的代码，机器执行起来出错率也高。
清理完一轮，评估结果会立刻往上跳一截。她演示的同一份 v0 评估，在 hygiene 跑完之后，对照用例与一部分边缘用例就已经稳定通过了，剩下要修的就是明确指向某个失败模式的边缘用例与边界用例。
05 三个失败模式：防御性补丁、指令 vs 能力、单边权衡
针对 Meridian Mobile 的评估，她演示了三种典型失败模式与各自的修法。
失败模式 1：防御性补丁过拟合。客户问"我的不限量套餐有多少 Hotspot 流量"，模型没答出来，提示用户去账户链接自查。翻看提示词，发现里面塞了一句"老套餐用户费率不同，绝不能给客户错误的套餐信息"。模型在过度执行这条防御性指令，把已知信息也扣住了。修法是把这条改为平衡表述：老套餐用户的额度不同，但具体数值已在客户信息中给出，且该信息才是准确事实来源。这条教训的反直觉之处是：除了担心模型"幻觉"凭空捏造，还要担心相反情况——模型可能"扣住"自己其实掌握的信息不予回答。修这种补丁要做版本控制，引入防御性变更时记下原因，便于后续回退。
失败模式 2：指令不等于能力。客户问"若升级到 30GB 套餐，下一账单金额是多少"，模型输出了大段心算过程，却没给具体数字。提示词里只写有"切勿给客户含糊答案，务必正确计算所有按比例金额"等泛化要求。修法不是改指令，而是提供工具——告诉模型有 calculate_proration 这个工具可用、定义工具 schema、实现数学逻辑。重跑评估之后所有相关用例都过了。教训是：指令不会赋予模型能力，告诉模型"必须算对"不会让它心算更好；正确做法是给工具，让模型能推理难题、让工具可靠地执行。
失败模式 3：单边权衡。期望行为是遇到账单冲突时升级给人工，模型却自己试着解释和诊断。翻提示词发现，里面写着"除非绝对必要，否则避免升级到专员，因为每次升级约 8 美元，并影响团队的快速解决率"——而评估要求的是必须升级。提示词在单边阻止升级。修法是讲两面：升级一次 8 美元，但如果判断错误，将造成退款与客户信任损失。模型会针对给定目标做优化，这类单边权衡的指令在历代模型上行为差异很大；模型越聪明，越要明确说明权衡的两面，让模型自己做出更好的权衡。
06 从零构建智能体：3 个维度同时考虑
场景切换到从零构建：典型例子是给零售门店排一周的班——根据员工可用性与硬约束（人不能同班、法定休息、最大工时）跑出合规排班表。从零构建有 3 个维度必须同时考虑：提示词、所选模型、运行框架（harness）。三者互相耦合，单点优化通常不解决问题。
她特别强调，有硬性规则时不要拿 LLM 当裁判用。不要让另一个大模型去评这个大模型生成的排班"对不对"。正确做法是写一个 Python 函数，对每个生成的排班统计违规数，机械判定。这条铁律的代价是损失一部分软性判断（比如"配合度"），但换来的是稳定可复现的评估。
07 五种方案对比：从 Sonnet 到智能体循环
同一道排班题，她跑了五种方案，结果是这么排的：
- 小模型 「Sonnet 4.6」：5 个测试用例全失败，模型尝试推理，但消耗大量 token，且没自检。
- 大模型 「Opus 4.7」：仍全失败，但整体违规数显著下降——更强的推理能力在改善结果，但还不到能发布的程度。
- Opus 4.7 配合 adaptive thinking 模式：保持 Opus 模型，让模型自己决定思考深度。稳定生成合规排班表，但 token 用量与延迟都约变成三倍（延迟约 100 秒，需要异步运行）。
- Sonnet + 优化 prompt（要求自检）：补推理指引，并要求模型在输出前自检。5 个用例中通过 2 个。失败原因是模型在输出 token 上限内无法完成任务。
- 智能体循环（generate→evaluate→repair）：以更低 token 与更低延迟通过全部测试用例，优于上一条用优化 prompt 的 Sonnet。
五种方案的对比说明了几件事。更大的模型有效，但远不是银弹；要求模型自检有用，但撞上输出 token 上限就崩溃；智能体循环之所以胜出，不是因为某一个 prompt 写得特别巧妙，而是把任务拆成了三段、每段独立运行、错误可以在中间被纠回。
08 3 段 prompt 拆解：生成、评估、修复独立运行
智能体循环的三段 prompt 各自简单、彼此独立：
- 生成（generate）：先产出排班初稿，逻辑上不要求它一步到位。
- 评估（evaluate）：用第二个 prompt 逐条规则审核，列出每项违规并提供证据——这里不用 Python 函数（那是离线评估用的），而是用模型自评，便于在运行时加入软性规则。
- 修复（repair）：用第三个 prompt 接收评估反馈，进行针对性修正。
关键在于三个 prompt 保持简单且彼此独立运行，而不是塞进单个大 prompt。这样做的额外好处是：支持运行时加入软性约束，例如 Harry 不喜欢和 Sally 一起工作，尽量分开，或者周三需要第三班次——这些是软规则，不必每次都修改后端 Python 评估函数。灵活性和可扩展性比单 prompt 高得多。
09 综合方法论
两类场景的实战走完之后，可以归纳成四条方法论。
通用卫生原则（基础规范）能立即提升评估表现，这一项要排在锁定失败模式之前。必须配套评估，以严格量化 prompt 改动对输出的影响；评估是回归测试的基线，没有评估的提示词调整都是盲改。流程化方法有效：逐个锁定失败模式、增加结构化约束、避免冗长的禁用词列表等，推动模型产出正确行为。新智能体场景的关键经验：拆成三套独立 prompt 系统，胜过单条 prompt 覆盖所有任务。隔离不同任务，使每一步可重复、易拆分执行。
10 编者按：边界、口径，和今天就能做的一件事
边界先摆三条。其一，这场分享的演示是演讲者在会议现场跑的，模型与工具的具体表现会因版本、API 参数、上下文窗口设置而异；她演示时明确说了这句：this is a pretty good first pass。其二，本场属于 Code with Claude 大会的分会场内容，演讲者本人的原话是 today we are looking at a miniaturized example，真实业务的提示词通常更长、更复杂；她给出的判断不直接外推到生产。其三，文中提到的三种失败模式、三段循环、adaptive thinking 等机制，会随模型版本演化；动手前以你手头模型的最新文档为准。
素材口径也要交代：本文事实取自这场三十三分二十四秒的演讲，演讲者身份以视频自我介绍为准（Margot Van Laar，Anthropic 伦敦应用 AI 工程师），视频原帖由 X 账号 @RahulTechX（运营者 Rahul Kumar）发布。全文未外引素材之外的事实——不补 Claude 模型的版本号、不补 Code with Claude 大会的届次日期、不外推智能体框架的实现细节。
编者判断说一句：这场分享真正值得记的不是某条 prompt 模板，而是把"先建评估"和"先做卫生清理"摆在锁定失败模式之前的纪律感——很多团队反着来，跳过评估直奔调提示词，结果改了一周不知改对没有。另一条是"指令不等于能力"——心算、复杂规则、长链条推理这类任务，正确的解法几乎都不是更好的指令，而是工具或拆分。
若只带走一个动作：现在就回看你手头那个最像 Meridian Mobile 的客服/助手提示词，先建一个 5 条用例的最小评估套件（至少 1 条对照、2 条边缘、2 条能力边界），用 v0 跑一遍，再做一遍通用卫生清理——对照用例挂掉就停下来，先把卫生做对再聊别的。
原作者：Margot Van Laar（Anthropic 伦敦应用 AI 工程师，身份以视频自我介绍为准）；本文观点出自其在 Code with Claude 开发者大会分会场的演讲（33 分 24 秒），视频原帖由 X 账号 @RahulTechX（运营者 Rahul Kumar）发布。