北京
Claude Code、Cursor、Copilot、Devin、Codex、Droid——过去一年，6大主流AI编程代理的能力都在突飞猛进。它们能规划多步骤任务，跨文件编辑，运行测试，还能自主迭代输出。
但工程团队的反馈却出奇一致：小任务跑得顺，一跨系统边界就摔跤，大把算力浪费在探索本可避免的死胡同里。
问题不在代理本身，在上下文。
Thoughtworks、Anthropic和一线开发者已经达成共识：筛选模型能看到什么，是提升输出质量的最杠杆动作。Anthropic工程团队的原话是，有效的上下文工程意味着找到最小的高信号token集合，最大化期望结果的实现概率。
但这里有个关键区分——配置代理（写CLAUDE.md、设规则、定义技能）和给它关于系统的深度结构化知识，是两回事。配置告诉它怎么表现，知识给它推理的素材。
Agent Boosting就是填这个坑：给编程代理配备持久、结构化的代码智能，让它发挥真实能力上限，而不是在陌生代码里跌跌撞撞。
看个对比。没有Agent Boosting时：开发者让代理修复Sphinx文档构建中继承属性缺失文档字符串的bug。代理读了相关文件，定位到文档字符串获取逻辑，打了补丁。局部看是对的，测试却挂了。代理迭代调整、加边缘情况处理、探索相邻文件。20分钟、几千token后，开发者介入才发现根因：属性在成员枚举阶段就没被收集，是上游完全另一处函数的问题。代理在错误的地方修对了症状。
有Agent Boosting时：同样的人、同样的代理、同样的任务。但代理启动前，先通过MCP查询CoreStory的智能模型。CoreStory扮演两个角色：一是Oracle，回答Sphinx文档管道的设计意图、数据流什么样、哪些不变量必须保持；二是Map，提供代码库的语义结构——关键抽象在哪、数据怎么流动、这个bug相关的上游依赖是什么。
代理拿到这些信息后，直接定位到成员枚举函数，发现属性收集逻辑缺失，一次修复通过。没有迭代，没有死胡同，没有token浪费。
区别很清晰：没有Boosting，代理在探索；有了Boosting，代理在推理。
这个模式正在快速普及。Cursor的"notepads"、Claude的CLAUDE.md、各类MCP服务器，本质上都在做同一件事：把分散的代码知识变成代理能消费的格式。但多数方案停在表面——静态文档、手动整理的规则、项目级的提示模板。
真正的Agent Boosting需要更深：自动提取代码语义、追踪数据流、维护随代码演化的实时知识图谱。不是让代理读更多，是让它读到对的东西。
对工程团队来说，这意味着重新分配注意力。与其调提示、试不同代理、盯着输出猜它为什么跑偏，不如投资代码智能基础设施——让代理"看见"系统的真实结构。
能力已经在那了，缺的只是让它发挥的信息。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
