Agent 总在瞎猜，问题多半出在你给它的上下文
Agent 总在瞎猜，问题多半出在你给它的上下文
先明确一件事：这里说的「上下文」，指 AI 在开口之前能读到的全部信息——项目里受 Git 跟踪的文件、你当前停留的页面、被点名的议题与流水线日志，以及通过 MCP 和自定义规则补进来的外部内容。极狐GitLab Duo 把这些信息按「始终可用 / 基于位置 / 显式引用」三类组织，能读到什么，直接决定它答得像不像个懂行的人。
为什么同一个问题，两个团队问出两种答案
先看一个很常见的场景。两位工程师都在用 Duo 分析同一个报错：「这个接口最近为什么变慢了」。
第一位直接把这句丢进对话，得到的是通用排查清单——查慢查询、看连接池、加索引。清单没错，但和他的项目没有半点关系。
第二位先在对话里挂上具体的合并请求编号，再补一句「只看 services/payment 目录下的改动，最近三天」。回答立刻变得具体：它会去读那个 MR 的 diff，指出某次改动把一次批量查询拆成了 N+1 次单条查询，并给出改写后的代码位置。
差别不在模型，而在上下文。极狐GitLab Duo 每次回答都建立在「它能看见什么」之上，而这个范围是可调的——很多团队从来没调过。
官方文档把 Agentic Chat 的上下文来源写得很清楚：通用编程知识、整个项目及所有受 Git 跟踪的文件、搜索 API（用来找相关议题和合并请求）、以及当前页面的标题和 URL。此外，它还会自动从 SDLC 数据、知识图谱、MCP 客户端和自定义指令里检索必要信息。更关键的一点是，与需要你提供精确 ID 或 URL 的普通 Chat 不同，Agentic Chat 可以自己搜——你问「找一下跟鉴权有关的合并请求」，它真的会去搜。
但「能自己搜」不等于「搜得准」。范围越宽，越容易把不相关的文件当成依据；范围越窄，又容易漏掉关键约束。真正的功夫在中间那一段。
四步把上下文从「随缘」变成「可控」
第一步：先弄清 Agent 到底能看见什么
在动手调之前，先把清单对着自己项目过一遍，这一步能省掉后面大量猜测：
上下文类型 | 具体包含 | 你需要做什么 |
|---|---|---|
始终可用 | 项目全部受 Git 跟踪文件、搜索 API、当前页面标题与 URL | 确认敏感文件不在仓库里，或在排除项里 |
基于位置 | IDE 中已打开的文件；UI 中当前所在页面（如某个 MR 或议题） | 注意打开着的文件会被当依据，切走前先关掉无关文件 |
显式引用 | 文件、史诗、议题、合并请求、CI/CD 流水线与作业日志、提交、工作项 | 在提问时点名，比让它自己猜准确得多 |
这张表里最容易被忽略的是「基于位置」那一行。很多人抱怨 Agent 引用了不相干的代码，回头一看，是 IDE 里同时开着五六个标签页。
第二步：用显式引用把范围钉死
与其指望模型猜中，不如直接把靶子递过去。同一个问题，两种问法的效果差异极大：
# 模糊提问，Agent 只能靠猜
这条流水线为什么失败？
# 显式引用，范围可复现
看一下流水线 #1284 的 deploy 作业日志，只分析最后 30 行报错；
相关改动在合并请求 !512 里，重点看 charts/ 目录的 values 变更。显式引用之所以有效，是因为它同时缩小了两件事：搜什么，以及不搜什么。团队里可以把这类提问方式写成一句话约定——凡是涉及具体失败，必须带上流水线编号或 MR 编号——成本极低，效果立竿见影。
第三步：用 AGENTS.md 把团队规范固化下来
靠每次提问重复叮嘱「我们不用 var，用 let」是撑不住的。极狐GitLab 支持用自定义规则或 AGENTS.md 把项目特定的上下文、编码标准、团队实践喂给 Chat、Agent 和任务流。放进仓库，等于让每个新加入的 Agent 会话自动继承团队约定：
# AGENTS.md
## 技术栈约束
- Node.js 20 LTS，包管理器统一用 pnpm，禁止提交 package-lock.json
- 后端接口一律走 services/ 下的封装层，不要在组件里直接 fetch
## 代码审查要求
- 新增依赖必须在 MR 描述里说明理由和体积影响
- 数据库变更必须同时提供回滚脚本，放在 db/rollback/
## 禁止事项
- 不要在提交信息里引用内部工单系统的原始链接
- 不要建议引入新的状态管理库这份文件的价值不在于写得全，而在于它把「隐性共识」变成了「可检索文本」。要注意的是它也属于上下文的一部分——写进去的每条规则都会影响输出，所以别把过期规范留在里面。
第四步：需要外部信息，走 MCP 而不是粘贴
Agent 看不到你的监控面板、内部知识库、工单系统。把这些数据接进来的正规做法是模型上下文协议（MCP），而不是每次手工粘贴一大段日志。
接之前先想清楚边界：MCP 客户端拿到的工具权限，会成为 Agent 能触达的实际范围。给一个能读工单的 MCP 服务，等同于给它开了一扇通往内部系统的窗。权限设计和上下文设计是一件事，不是两件。
第五步：把不该看的挡在上下文之外
专业版和旗舰版提供了上下文排除项：在项目左侧边栏进入「设置 > 通用」，找到「极狐GitLab Duo」下的上下文排除项，选择「管理排除项」，指定需要排除的目录或文件后保存。被排除的内容，所有 Duo Agent Platform 功能都会跳过。
典型需要排除的是这几类：.env 与各类密钥配置、含有客户真实数据的 fixture、内部商务合同。排除动作要放在项目初始化的清单里，而不是等出事之后补。
三个真实存在的坑
坑一：排除项不是绝对的。 官方文档记录了两个已知问题：MCP 服务器的 get_merge_request 工具在拉取差异时不会检查排除项，可能返回包含已排除文件内容的 diff；add_commit 工具的 move 操作也不会对源路径做排除检查——有推送权限的 Agent 可以把已排除文件移动到未排除路径再读取。这两个问题记录在议题 628141 中。结论很直接：排除项是减面措施，不是权限边界。真正敏感的东西，不该让它躺在仓库历史里。
坑二：IDE 里开着的标签页就是上下文。 官方明确说明，IDE 中已打开的文件会被当作上下文。开着生产配置文件问问题，等于主动把它递过去。养成习惯：提问前关掉无关文件。
坑三：别拿普通 Chat 的用法套 Agentic Chat。 普通 Chat 需要你给出精确 ID 或 URL 才能定位资源，Agentic Chat 可以自主搜索。反过来说，用普通 Chat 时抱怨「它找不到我的 MR」，多半是没给编号。
常见问题
Q：上下文给得越多，回答就越准吗？
不是。多而杂会稀释重点，模型需要在无关文件里做筛选，反而更容易抓错依据。有效做法是「精准 + 少量」：点名具体资源，再补一条范围限定。
Q：AGENTS.md 和自定义规则有什么区别，要都写吗？
两者都是给 Agent 提供项目特定上下文的机制，用途重叠。团队约定写在一处即可，分散在多处容易出现互相矛盾的规则，反而制造噪声。
Q：排除项配好了，是不是就不用管敏感信息了？
不是。如上文所说，MCP 侧存在绕过路径。排除项用于降低误引用概率，敏感凭证仍应放在变量或外部密钥管理里，不进仓库。
想动手试一遍？ 上下文感知的完整说明在文档中心，其中包括 Agentic Chat 与软件开发任务流各自可用的上下文清单。如果你正在评估 Agent 落地的边界，申请专业版试用 后可以直接在项目设置里配一遍排除项，十分钟就能看清「管」和「不管」的差别。
