给编码代理正确的上下文（而不是更多）

一句要求登录端点的句子是不够的。代理仍然需要知道你的错误格式、文件夹布局、认证库、验证模式，以及「完成」看起来像什么。Legare Kerrison 的 IBM Technology 短视频 Context-Aware Coding: Give AI Agents the Right Context（2026 年 11 月 2 日发布）对已经在使用编码代理的团队来说，把这一点讲得具体且实用。

这不是另一篇高层瓶颈文章。它是一份真正改变输出的输入短清单。

重要的输入

1. 文件和结构。 强大的代理可以自己搜索和打开文件。你的工作是把它们指向正确的方向（「遵循 README 中的模式」），理想情况下给它们一份紧凑的仓库文件和符号地图，让它们看到形状而无需阅读每一行。

2. 确切的依赖版本。 知道你使用某个库是不够的。锁文件记录了解析后的版本（包括传递依赖），因此也记录了哪些 API 实际存在。许多「幻觉」函数只是版本不匹配。

3. 代理可以通过的测试。 失败的测试把会话变成写–运行–修复循环。当代理知道好的样子时，代理编码效果更好。

4. 约定和约束。 把构建命令、编码标准和硬规则（「不要碰这个目录」）放在已检入的 AGENTS.md（或你的工具已经读取的等价物）中。这正在成为共享的团队接口。

5. 意图。 只有人类知道完成意味着什么、约束是什么，以及代理绝不能做什么。代理无法通过阅读仓库发现这些。

在写任何代码之前的三个动作

• 让代理采访你，并持续提问直到它理解任务。
• 告诉它探索仓库并用通俗语言向你解释结构。现在你们共享一张地图。
• 让它写一份计划并列出假设。在实现前审查这些假设。当会话结束时，把有用的发现写回指令文件，让下一个人（或代理）从更远的地方开始。

不要倾倒整个仓库

模型不会对长上下文中的所有内容给予同等关注。开头和结尾的信息往往比埋在中间的材料使用得更好（「lost in the middle」）。每个不相关的文件都在与相关文件竞争。对于登录流更改，代理需要认证模块、它的测试和约定——而不是计费服务或三周前的构建日志。

实际后果：

• 为每个新任务开启新会话。
• 指向特定文件，并在会话变长时清理噪音。
• 优先使用能以干净上下文启动聚焦子任务的编排器，而不是一个过载的对话。

目标不是更多上下文。而是正确的上下文，同时仍由人类做决策。

Hacker News 上的相关讨论继续指出，代理生成的代码多于它们生成的完成、可维护的软件；审查和验证仍然是稀缺步骤。更好的上下文不会消除这些步骤，但它会减少到达这些步骤的垃圾数量。

来源：上面链接的 IBM Technology 视频。相同主题出现在最近的 Agentic AI Foundation 和 AI Engineer 关于代理准备和共享接口的讲座中，但简短具体的清单是让这个视频在周一早上有用的原因。