微软：代理评估中的隐性变量

本文讨论在构建AI代码代理评估时常被忽视的“隐性变量”，如操作系统、文件路径、用户标识符和开发工具反馈，如何无形中改变代理行为并扭曲评估结果。作者建议在多环境下运行评估并显式固定或审查这些外部因素以获得更具代表性的测量。

背景
– 本文为Agent Experience（AX）系列文章之一，聚焦让AI代码代理在你技术栈中可靠工作的实践。作者指出，即便你固定了模型、提示和工作区，评估结果仍可能因未控制的环境因素而不一致。

关键隐性变量与影响
– 操作系统与Shell
– 不同OS（Windows vs macOS/Linux）会使代理默认使用不同Shell（PowerShell vs bash/zsh），影响命令运行、错误解析和多轮迭代的行为。模型在Unix风格Shell上的表现通常更流畅。
– OS还会影响技术栈偏好：在相同提示下，某些模型在Windows倾向.NET，在Linux更倾向Python/Node.js。

• 文件路径与用户身份
• 绝对路径中的单词（如azureuser、azure、poc、test）会反复出现在提示上下文中，强化特定偏好或假设，进而改变代理的设计选择（例如偏好Azure、跳过鉴权、使用硬编码）。

• 当提示模糊时，这类路径信号会成为决定性因素，导致评估反映的是运行环境而非模型能力。

• 语言服务器与构建反馈

• 代理会实时读取LSP诊断和构建错误，基于这些工具输出调整生成。工具反馈变成会话上下文的一部分，影响行为轨迹。

实务建议
– 在多环境上跑评估：至少覆盖不同操作系统和Shell，识别因环境差异导致的偏差。
– 固定并审查工作区路径：避免使用包含供应商或示意词（azure、poc、test）的目录名；在评估规范中声明路径。
– 明确提示与约束：当你需要测量具体能力时，给出明确的技术栈、质量和安全要求以覆盖环境信号。
– 记录工具输出：将LSP、构建日志纳入评估记录，以便回溯代理为何做出某些修改。

结论
– 单一环境的评估并非“错误”，但结果不具备普适性。理解并控制这些隐性变量，或在多环境中比较，能让评估更可靠并更贴合真实开发者体验。

在评估代理时别只看模型和提示，环境细节往往比你想的更会左右结果。

原文链接