路径里的 eval 会改变 agent 行为吗：把工作区命名当作提示面

短答：路径会进入模型的上下文，这一点在材料里有依据；但“带 eval 的路径是否真的改变 agent 的行为”，材料只给出“可能”这一层，不能当成已测结论。以下判断基于微软开发者博客该文的摘要（正文未获取，摘要句子在“系统提示”处被截断），所以我只把结论收窄到“路径是一条提示通道”这一步。

路径为什么算输入，而不是背景#

据该文摘要，评测工具需要每次运行都拿到一个全新目录，最省事的办法是用随机名的临时目录，例如 /tmp/eval-7f3a2c；而 agent 在每一轮都能看到这个路径。摘要原文的说法是“在你的 agent 读到第一条指令之前，路径可能已经在告诉它这是一次测试”（来源：Does ‘eval’ in the workspace path change what your agent does?）。

这条通道不止一处：当前工作目录、ls 之类的工具返回、报错栈里的绝对路径、补丁与 diff 的文件头，都可能把同一个字符串送进上下文。只要路径出现在这些位置，它就和指令共享同一个文本面。

“eval” 这个词的特殊性#

eval-7f3a2c 同时包含两段信息：一个在训练语料里高频出现、与“评测/打分”强相关的词，以及一段随机串。随机串消除了碰撞，却没有消除语义。由此可以合理推断：模型可能据此判断“输出会被评分”，进而更保守、更啰嗦，或更倾向于表演式完成任务。这是推断，不是实测结果；不同模型与框架差异很大，需要在你自己的 harness 里验证。

命名污染的两个方向#

• 向“考试”方向偏：eval、test、benchmark 之类目录名可能改变输出的谨慎程度与格式。
• 向“可丢弃”方向偏：tmp、backup、prod-copy 这类名字可能让 agent 低估操作后果——这同样属于推断，但风险方向相反，值得一并观察。
• 注入面：若目录名可被外部影响（解压包、克隆的仓库名、用户自建目录），路径本身就成了一条可控文本通道。这是通用风险判断，不是该摘要陈述的事实。

把命名从提示里摘出去的做法#

1. 先观测再断言：打印实际发给模型的完整上下文，确认路径出现在哪几个位置、出现几次。
2. 用中性前缀命名，如 run-<随机串>，避开 eval/test 等语义词。
3. 把“这是测试环境”写成显式指令，而不是靠路径暗示；显式指令可被审查，路径暗示不可。
4. 对模型侧做路径归一化：宿主机真实路径保留在日志里，喂给模型的统一显示为 /workspace。
5. 要判定是否影响行为，固定任务、提示、模型与工具集，只改目录名，先定样本量与判定标准，再比较差异。

# 演示代码，未执行；仅示意中性命名与路径归一化
import tempfile, uuid, pathlib

run_id = uuid.uuid4().hex[:8]
root = pathlib.Path(tempfile.mkdtemp(prefix=f"run-{run_id}-"))  # 不含 eval/test 等语义词
workspace = root / "workspace"
workspace.mkdir()
# 传给 agent 的路径统一显示为 /workspace，宿主真实路径只进日志

边界#

改名只是减少一条噪声通道，不构成提示注入的防线。注入边界仍要靠输入分区（哪些文本是指令、哪些只是数据）、工具权限最小化与危险操作的人工确认。至于这条路径在真实评测中带来多大偏差，本次材料不足以给出数字，属待核实范围；建议把它当作一个需要用对照观察回答的问题，而不是一个可以凭直觉下结论的现象。