Agent 写出了"正确但没用"的代码

你有没有遇到过这种情况？

你让 AI Agent 帮你写一个用户管理模块，它很快输出了一段代码——结构清晰、命名规范、还有完整的单元测试。代码质量没得挑。

但你的产品是一个多租户 SaaS 平台。每个租户有自己的配置空间、独立的权限体系、数据完全隔离。Agent 写出来的是一个"通用"的用户管理模块，完全没考虑多租户的场景。

于是你花大量时间补这些逻辑：租户隔离的中间件、租户级别的配置管理、跨租户操作的权限校验……最后你发现，Agent 帮你省下的时间，又被你花在了解释业务上下文上。

这不怪 Agent。它缺的是你的业务模型知识——那些没写在代码里、散落在团队脑中的领域知识。

SaaS 的业务模型为什么特别复杂

SaaS 产品和普通软件的核心区别在于业务模型的复杂度是多个维度的。

多租户架构——数据隔离策略是共享数据库还是独立数据库？租户级别的资源配额怎么分？租户间的数据边界在哪？

多版本管理——免费版、专业版、企业版的功能矩阵差异，版本升级的迁移策略，灰度发布的版本控制。

多配置体系——租户级别的自定义配置、用户级别的偏好设置、全局的系统配置。三层配置的优先级和覆盖规则。

计费模型——按席位、按用量、按模块的混合计费，账单周期，试用期逻辑。

集成生态——Webhook 机制、API 限速策略、第三方集成的鉴权方式。

这些知识通常不在代码里直接体现，散落在产品文档（如果有的话）、架构设计文档（可能已经过期）、团队成员的脑子里（最难获取的那种）、历史 PR 的 comment 里（最容易被遗忘的那种）。

Agent 缺少这些知识，写出来的代码只能做到"通用正确"，不是"业务正确"。

解决思路：怎么把业务知识喂给 Agent

这个问题有几种常见的解法，各有利弊。

最朴素的方式是手动写 System Prompt 或者 .cursorrules 文件，把核心业务规则写进去。好处是简单直接，坏处是维护成本高——业务规则变了你得记得同步更新，而且 Prompt 长度有限，放不下太多内容。

另一种做法是把业务知识组织成文档，让 Agent 在编码时按需检索。这本质上就是一个 RAG 系统——你需要的是一套能把业务知识结构化存储、并按上下文自动检索的机制。

我在 RDS ContextDB 上试过第二种思路。它的三层记忆架构比较适合组织 SaaS 业务模型这种层次分明的领域知识。

把业务模型转化为结构化知识

原子事实（Atomic Fact）层把每条业务规则提取为最小单元：

• "租户数据使用 schema 级别隔离，每个租户对应一个独立 schema"
• "免费版用户上限为 10 人，专业版为 100 人，企业版无限制"
• "租户级配置优先级高于全局配置，用户级配置优先级高于租户级配置"
• "API 限速：免费版 100 次/分钟，专业版 1000 次/分钟，企业版 5000 次/分钟"

记忆实体（Entity Card）层把相关原子事实聚合起来。"租户隔离策略"实体包含数据隔离方式、schema 命名规则、跨租户操作限制。"版本功能矩阵"实体包含各版本功能清单、限制条件、升级路径。

记忆图谱（Memory Graph）层把实体之间的关联显式记录下来。"租户隔离策略"关联"数据访问层"——因为所有数据库查询都要带租户 ID。"版本功能矩阵"关联"权限控制模块"——功能开关直接影响权限设计。

编码时自动检索相关知识

Agent 写代码的时候，系统会根据代码上下文自动检索相关业务知识。

Agent 在写一个数据库查询函数，系统自动注入："租户数据使用 schema 级别隔离""所有数据库查询必须包含 tenant_id 过滤条件""跨 schema 查询需要通过统一的 CrossTenantQueryService"。

Agent 在实现一个功能开关检查，系统注入："功能开关分为全局开关和租户级开关""检查顺序：先查租户级，未设置则 fallback 到全局"。

实操：怎么搭起来

接入：

curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>

先把已有的架构文档、产品文档、API 文档导进去，作为初始知识库。这一步大概能覆盖 60-70% 的核心业务知识——说实话，冷启动阶段的效果一般，需要一定的积累才能明显感受到差异。

之后团队在日常用 Agent 编码的过程中，系统会自动从对话中提取新的业务知识。开发者向 Agent 解释了一个复杂的业务规则、Agent 在调试中理解了某个配置项的含义、代码审查中讨论了一个架构决策的原因——这些交互都会被提取为原子事实，逐步丰富知识库。

然后利用"AI 筛选 + 人工拍板"机制，定期审查待审核队列。确认 AI 提取的业务知识是否准确，补充遗漏的知识点，标记过时的知识让系统自动降低置信度。

一个实际的对比

假设你让 Agent 写一个"创建新租户"的函数。

没有业务上下文的时候，Agent 输出一个标准的 CRUD 函数——创建一条租户记录、返回租户 ID。看起来没毛病，但缺了大量 SaaS 特有的逻辑。

有了上下文积累之后，Agent 在写代码之前自动检索到了这些业务知识：创建租户需要同时创建独立的 schema、需要初始化默认配置（从模板复制）、需要创建默认的 admin 用户、需要初始化计费信息（试用期 14 天）、需要发送欢迎邮件和 API Key、需要在审计日志中记录操作。

最终输出的代码覆盖了这些业务逻辑，做到了"业务正确"而不只是"语法正确"。

当然，这个效果取决于知识库的积累程度。刚接入的前一两周，体感改善不明显。大概积累了几百条原子事实之后，差距才开始变得明显。这不是一个"接入即见效"的方案，更像是越用越好的类型。

让 Agent 像一个了解业务的团队成员

SaaS 团队做 AI Coding，不应该只是"让 Agent 写代码"。你应该让它像一个了解业务的团队成员一样写代码。

这个差距的关键在于上下文——Agent 是否理解你的业务模型。无论是用 System Prompt 硬编码规则，还是用 ContextDB 这样的结构化知识库来管理，核心都是把团队积累的 SaaS 领域知识传递给 Agent。

不用每次都在 Prompt 里写一大段业务背景说明了。Agent 有了自己的"业务记忆"，用得越久，对你的产品越熟。不过也别忘了定期清理过时的知识——业务规则是会变的，Agent 的记忆也需要跟着更新。

参考链接

• RDS ContextDB 快速入门