今天选择两篇 2026 年 10 月 28 日提交的原创论文，讨论 Coding Agent 必须处理却容易误用的同一种输入：来自真实工程系统的证据。第一篇研究“找到的代码能否用于当前部署”，第二篇研究“运行时诊断能否指挥 Agent 执行操作”。两篇均是预印本；前者属于小规模可行性验证，后者属于受控安全实验，不能直接当作真实生产环境的性能或风险比例。
1. When Relevant Code Is Wrong: Runtime-Aware Context for AI Coding Agents
- 作者/来源： Wesley K. G. Assunção、Ramesh Periyathambi / North Carolina State University、eBay
- 发布日期： 2026-10-28（arXiv v1，UTC）
- arXiv 原文： https://arxiv.org/abs/2610.38800
- AlphaXiv： https://www.alphaxiv.org/abs/2610.38800
推荐理由： 代码搜索通常优化相关性（relevance），但同一个仓库可能同时保留旧 REST 接口、新 GraphQL 实现与不同地域的 Feature Flag 配置。检索结果“与任务相关”，不等于“对当前部署有效”。论文把这种差异明确形式化，并提出 CASE：给 Agent 的上下文附上部署范围、证据时间与有效性标签，而不是一股脑提供最相似的文件。
3 条核心要点：
- 适用性需要任务、部署和时间三个坐标。 CASE 将候选代码、PR、测试及架构文档关联到服务路由、Feature Flag、迁移记录等带时间戳的证据，把结果区分为
valid / invalid / unknown。有效结果才能放入 Act On；不确定的放入 Verify；已失效但有解释价值的放入 Explain。旧代码不一定错：同一 REST 实现在美国部署可能已被 GraphQL 替代，却仍在欧洲回滚后的部署中有效。 - 检索命中率不能替代适用性判断。 作者在 Java/Spring Boot 的模拟 merchant-trust 应用上评估 6 项任务、15 份工件、3 个部署，使用相同候选池和约 1,500 Token 预算。普通检索的可执行上下文精确率为 0.50，包含 16 次不兼容工件出现；180 天时间过滤把不兼容项降至 6 次，但有效召回率也降至 0.43。CASE 在其自身参考规则下达到了 1.00 精确率、1.00 召回率，并将不兼容/未知证据从可执行部分移走。
- 结果说明机制可行，尚不能证明 Agent 修复得更好。 去掉 Feature Flag 证据后，CASE 的有效召回率由 1.00 降至 0.13。但实验的工件关系由人工整理，参考标签与 CASE 判定规则相同，完美分类并非独立泛化证据；研究只测上下文选择，没有测生成 Patch、任务完成率或线上故障减少。下一步仍需要独立真值和真实工程任务的对照测试。
核心启示：
Retrieved Artifacts → Deployment/Flag/Time Evidence → Valid / Invalid / Unknown → Act On / Verify / Explain。上下文应附带“为什么现在可用”的证据，不能把相关度或新旧程度当作事实权威。
2. CARI: Cross-Boundary Adversarial Runtime Injection in Coding-Agent Workflows
- 作者/来源： Jie Fu、Shuang Wu、Ashish Kundu、Wendy Hui Wang、Yuan Hong / Stevens Institute of Technology、University of Connecticut、Cisco Research
- 发布日期： 2026-10-28（arXiv v1，UTC）
- arXiv 原文： https://arxiv.org/abs/2610.38799
- AlphaXiv： https://www.alphaxiv.org/abs/2610.38799
推荐理由： Agent 处理测试失败、服务报错和 CI 日志时，通常会主动把诊断文字变成下一条 Shell 或文件操作。论文揭示一种很容易混淆的授权边界：协作组件有权报告故障，但没有权力命令另一位开发者的 Agent 修改本地环境。这是面向多 Agent 软件生产流水线的具体威胁模型，而不只是“恶意网页中藏了提示词”。
3 条核心要点：
- 运行时反馈本身可以携带越权指令。 CARI 的攻击者仅控制协作流程中的某个活跃组件（例如后端接口、测试服务或 CI 诊断），不直接修改受害者 Prompt、模型、工具、仓库或本机环境。Agent 为完成正常调试任务读取该组件返回的诊断，若错误地把“故障说明”升级为“操作授权”，就可能执行本不属于该组件权限范围的动作。相同恶意文本放在静态工件、被动日志和执行后直接返回的诊断中，实验所测成功率明显不同，说明信息到达的工作流位置影响信任判断。
- 受控实验规模较大，但风险比例有严格边界。 作者在 Python、Go、Java、Rust 的等价 Todo 应用中构造 10 种攻击、5 个模型、3,000 次试验，研究 Harness 下 **2,845 次（94.8%）**达到预设攻击目标。迁移到实际产品配置，原始攻击文本在 Codex 为 61.3%、Claude Code 为 58.7%。这反映特定研究任务、Agent/模型和攻击集合，不能解释为任意真实仓库有 94.8% 的被攻破概率。
- 仅靠 Prompt 约束存在安全—可用性冲突。 在作者的对照里，泛化安全提醒仍有较高攻击成功率；明确限制敏感操作能显著压低成功率，却也使大量合法修复请求遭拒。论文提出追踪运行时反馈来源、绑定组件授权范围、以最小权限拦截敏感动作等防线，但没有完成这些系统级防御的实证评测。关键不只是识别“这条信息是否可疑”，而是约束“这个来源能触发什么操作”。
核心启示：
Peer Runtime Feedback → Source/Scope Check → Untrusted Diagnostic Data → Authorized Action Gate → Tool Execution。诊断权不等于执行授权；运行时返回的文本不能自动升级成高优先级指令。
今日思考
两篇研究共同追问的是**“系统给出的证据，在什么条件下有资格改变 Agent 的行为？”**
CASE 关注事实适用性：一段代码或配置是否适合特定版本、部署和时间。CARI 关注行动权限：即使某条诊断出自当前运行的真实服务，它也可能来自不可信或权限较低的主体，不能直接要求 Agent 操作本地文件、凭据或网络。
因此，可靠的 Agent Harness 至少要分开两个判断：Evidence Validity（这份证据在当前状态下是否成立）与 Action Authority（产生这份证据的主体是否有权要求这个动作）。第一步决定上下文能否指导实现，第二步决定动作能否真正落地。最终结果仍需独立测试与审查，而不是由 Agent 自行宣称完成。