机器学习实验的搭建过程，比大多数人想象的要脆弱得多。
微软 ISE 团队在一次真实项目中碰到了这个问题：启动一个实验需要一长串手动步骤，没有哪一步特别难，但组合在一起就变成了高度容易出错的流程。用户要提供实验名称、假设、真值数据集，但格式没有规范，每个人填的都不一样。他们还要决定是复用现有基线还是新建一个，这对新人来说并不直观。然后是多个配置文件，推理、评估、实验运行器各有一套格式，需要分别手动更新。检索参数通过自定义检索码配置，需要知道正确的标志位。Prompt 要手写，没有样例，也没有校验。最后还要按顺序执行多个脚本来部署 Agent 并启动实验。
这还不算每个具体实验可能带来的特殊情况，比如你需要对每个实验排列组合分别变更推理模型。问题不是某个环节太难，而是整个流程太长，用户总是搭错。
四段式 Prompt 的设计
解决方案是创建一个专用 Agent，也就是 GitHub Copilot 里现在叫”chat mode”的功能。这个 Agent 的核心是一份结构化的 Prompt，分为四个部分。
第一部分是要向用户询问的问题清单。Agent 被要求一次性把所有问题问完，而不是一问一答地来回拉锯。问题包括：EXPERIMENT_NAME（实验唯一标识符）、HYPOTHESIS（假设陈述）、SPRINT（当前 sprint 目录）、GENERATION_METRICS（是否收集生成指标）、PERMUTATIONS（实验排列数量），以及是否是基线实验。只有用户明确说明是基线实验时才视为基线，否则默认当作标准实验处理。
第二部分是生成文件的操作指令。Agent 根据用户提供的信息在项目结构中创建实验目录，命名规则用下划线分隔单词，然后依次完成复制模板、补全 README、更新各配置文件等一系列操作。
第三部分是校验清单，这是整个方案中效果最显著的设计。Agent 会在一个追踪文件里记录所有检查项，逐一验证每个搭建步骤，完成后打钩。这个二阶段验证机制大幅提升了任务执行的完整性：先做，再自查，比单纯依赖 Agent 一次性完成要可靠得多。
第四部分是 FAQ，覆盖用户在实验文件生成后可能提出的问题。比如”我现在该做什么”，Agent 就会告诉用户先运行 add_codes.py 添加检索码，然后跑 provision.py 部署 Agent，最后执行 evaluate.py 运行实验并收集结果。
[ ] EXPERIMENT_NAME 已以描述性名称收集
[ ] HYPOTHESIS 已作为简短陈述收集
[ ] SPRINT 已收集（如 "sprint01", "sprint02" 等）
[ ] GENERATION_METRICS 决策已收集（true/false）
[ ] PERMUTATIONS 已收集并记录
[ ] 实验目录已用下划线命名方式创建（如 "my_experiment"）
[ ] 目录路径正确：/experiments/<experiment_folder>/
[ ] 已验证实验目录存在且所有后续文件均在此目录下模型选择比预期影响大得多
团队测试了所有主流模型，最终发现 Claude Sonnet 4 在这个任务上表现最好。更新的 Claude 版本也可以用，但效果稍逊；OpenAI 及其他厂商的模型”很少能正常工作”。为了保证一致性，他们把模型固定在 Agent 配置中。
除了 Prompt 之外，团队还开发了命令行工具供 Agent 调用，用于部署 Agent、设置检索码等操作。这些工具减少了 Agent 自己写代码的需要，可靠性随之提升。
还没解决的问题
这套方案效果足够好，但并不完美，团队也没有回避这些问题。
实验流程本身还是太复杂，选项和配置太多，就算是 Agent 也难以完整追踪。一个思路是把所有配置迁移到 Azure App Configuration，Agent 只需要用标签和标记来指定哪些配置与当前实验相关。
模型固定的问题在用户端难以约束：用户可以自行更改，一旦改了，几乎都会出问题。目前还没有一个好的方法强制限制解决方案只能跑特定模型。
用户描述实验意图的清晰度参差不齐。有时候是描述不够具体，Agent 按自己理解生成了错误的配置；有时候则是用户自己都没想清楚想做什么。一个可能的改进是让 Agent 先总结它的理解，在生成文件之前主动追问确认。
生成结果的可见性也是个问题。当文件多达几十个时，用户并不清楚究竟产出了什么。生成一份摘要，说明每个排列用了哪个推理模型、哪些检索码，会比让用户自己翻代码要友好得多。
实际效果
用 Agent 自动化实验搭建，速度和可靠性都有了明显改善。四段式结构的 Prompt 提供了一个可复用的框架：有问必问，按指令生成，自我校验，内置 FAQ。这套模式不只适用于 ML 实验配置，任何需要多步骤、多文件协同完成的设置流程，都可以套用这个思路。
参考
- 原文 — Peter Lasne，Microsoft ISE Developer Blog