遗留代码里的 Agent 不缺上下文窗口，缺的是领域边界

作者：林岚｜OC 开发者生态编辑

大模型在新项目里经常显得很能干：目录小、命名一致、约束少，几轮对话就能搭起功能。把同一个 Agent 放进十年遗留系统，效果往往急剧下降。Cold Take 的一篇实践文章提出，问题不只是上下文窗口不够，而是代码库本身没有稳定的领域语言和边界。

一句话结论：给 Agent 塞进更多文件，只会扩大噪声；更有效的做法是用领域驱动设计把业务概念、边界上下文和依赖关系变成可维护的工作地图。

遗留系统常见的困难不是代码“太多”，而是同一个词在不同模块含义不同、同一业务规则散落在控制器、数据库触发器和定时任务里。人类老员工可以靠历史记忆补齐隐含语境，模型看到的却只是互相矛盾的局部证据。于是它可能改对一个函数，却破坏另一个团队默认的业务不变量。

文章建议先建立上下文地图：识别订单、计费、身份等领域，各自使用什么词，谁拥有数据，边界之间通过什么接口交互。再把这些信息写入可被 Agent 读取的工作流文件和目录说明，必要时为不同领域配置专门子流程。重点不是做一份宏大的架构文档，而是让每次任务能定位到一组更小、更一致的规则。

这种方法还有一个容易忽视的收益：它迫使团队正视代码库里的语言债务。如果“客户”“账户”“租户”在三个服务里相互代指，Agent 的错误只是把人类早已习惯的歧义暴露出来。修正术语、声明所有权、加契约测试，本身就会改善人工维护，而不是为了迎合模型制造一套旁路文档。

当然，DDD 也可能变成新的仪式负担。自动生成一堆术语表而无人维护，过几个月同样会与代码漂移。领域边界应该连接到可验证资产：接口 schema、架构测试、领域事件、代码所有者和持续集成规则。Agent 可以帮助发现候选边界，但最终命名与权责仍需团队决定。

真正可落地的起点很小：选一个频繁出错的跨模块需求，记录它涉及的领域词、数据所有者和不可破坏的断言；把说明放到对应目录；再比较 Agent 在前后两种上下文下的修改范围和测试通过率。这样得到的是可测量的改进，而不是一场“让 AI 重写架构”的豪赌。

关键事实

• 来源：Cold Take 的领域驱动 Agent 实践文章
• 问题场景：强耦合、技术债务高、术语不统一的遗留代码库
• 核心方法：上下文地图、统一语言、领域边界与工具化工作流
• 目标：减少无关上下文，让模型在明确的业务约束内修改代码

OC 判断

问题不在模型能不能一次读完仓库。代码库若没有边界，把上下文窗口从 20 万扩到 100 万，只是让模型更快读到更多矛盾。DDD 在这里不是复古架构时尚，而是一种把隐性组织知识变成 Agent 可用、也可由人审查的接口。

为什么重要

• 对开发者：可以从一个领域和一条高频任务开始，不必先全面重构。
• 对团队：为 Agent 整理的统一语言也会降低新人上手和跨组协作成本。
• 对工具厂商：代码检索之外，还需要支持领域边界、规则作用域和可验证约束。

参考来源

• Domain-driven agents