建议将所有微服务放在一个workspace(monorepo或虚拟monorepo),让Agent同时看到schema、API和实现代码。文档采用分层结构:根目录AGENTS.md索引各服务职责,每个服务内写清bounded context。优先用OpenAPI spec等机器可读规格自动生成文档。协议测试(contract test)是精准活文档,能验证服务间交互。验证环节各服务提供mock server或基于OpenAPI的模拟服务,Agent在本地跑contract test形成“写代码→跑测试→自我修正”闭环。可进一步引入consumer-driven contract testing(如Pact)。
Q:我们公司有十几个微服务,现在想让开发用 AI Agent 来做系统设计和编码。问题是一个 user story 经常需要多个微服务协作,Agent 必须了解每个服务的职责边界和业务概念才能做出合理的设计。我们打算把所有微服务放到一个 workspace 下,每个服务配上自己的文档,让 AI 自己去处理。这种方式合理吗?有没有更好的实践?
A:用好 Agent 的关键是两点:上下文的质量,和验证的闭环。
先说上下文质量。
放在一个 workspace 下是目前社区比较推荐的做法。
monorepo 天然适合和 AI 配合,因为 Agent 可以在一个地方同时看到 schema 定义、API 协议、各个服务的实现代码。如果因为历史原因确实不方便合成 monorepo,有个折中方案叫虚拟 monorepo,就是把多个仓库 clone 到同一个本地目录下。
除了放在一起,文档也是很好的让Agent获取上下文的方式,最好给 Agent 一张地图,加上按需加载: 1. 根目录放一份总的 AGENTS.md(或 CLAUDE.md)当索引用,列清楚有哪些服务、各自负责什么、要改某个服务就去读它目录下的文档。 2. 每个微服务自己目录里再放一份,写清自己的职责边界和业务概念,这其实就是 DDD 里的 bounded context。 3. 让 Agent 先看根索引,定位到相关的那几个服务,再去加载它们的细节。