宝玉@dotey · X建议将所有微服务放在一个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 先看根索引，定位到相关的那几个服务，再去加载它们的细节。