别再只优化你的 Agent 了：构建智能体软件的五层系统工程
一、核心论点
“Coding agents lowered the barrier to writing code, but they haven’t lowered the requirements of production software.”
AI 让写代码变容易了，但没让”写出能上生产的软件”变容易。前者是 craft，后者是 engineering discipline。Vibe coding 能做 demo，做不了产品。
作者借贝尔实验室 1940 年代的教训：无法通过优化单个组件来优化整个系统。整个系统的行为取决于组件间的交互方式，而非单个组件性能。Agent 软件生态正在重蹈覆辙——用 filesystem 做 memory、用 bash 做通用工具，然后再往上打补丁。
二、五层架构
| 层 | 核心职责 | 关键原则 |
|---|---|---|
| Agent Engineering | 模型、指令、工具、交接、上下文、可观测性 | 行为尽量确定，不确定处可观测 |
| Data Engineering | 记忆、存储、知识库 | 用数据库，别用文件系统 |
| Security Engineering | 认证、RBAC、审计、数据隔离 | 安全是系统属性，不是 prompt 指令 |
| Interface Engineering | REST / Slack / MCP / CLI | 多端统一身份和权限 |
| Infrastructure | 容器、部署、水平扩展 | 95% 和传统服务一样 |
架构哲学：第 1 层是”非确定性业务逻辑”的容器，其余四层是围绕它的”确定性围墙”——用四圈确定性约束把中间那团不确定性围住。传统软件是 separation of concerns，agent 软件是 containment of non-determinism。
三、关键设计
3.1 相同接口，不同权限（硬约束 vs 软约束）
Dash 的 Analyst 和 Engineer 用同类工具但连不同 DB engine：
- Analyst → read-only connection（DB 层拒绝写操作，无论模型输出什么 SQL）
- Engineer → writable connection, scoped to single schema（query-level guard 限制写域）
原则：Agent 的能力差异化应通过工具配置实现，而不是通过 prompt 实现。Prompt 是软约束——模型被诱导后可能违规。配置是硬约束——系统层直接拒绝。
推广表：
| 软约束（prompt-level） | 硬约束（config-level） |
|---|---|
| “只在 /tmp 下写文件” | fs 工具 chroot 到 /tmp |
| “不要调用外部 API” | container egress 防火墙白名单 |
| “不要读取用户 B 的文件” | DB query 强制注入 WHERE user_id = A |
3.2 六层数据上下文
| 层 | 内容 | 性质 |
|---|---|---|
| Table metadata | schema, columns, relationships | 自动拉取 |
| Human annotations | 指标定义、业务规则 | 人工写入 |
| Query patterns | 已验证的 SQL 查询 | 半自动积累 |
| Institutional knowledge | 文档、wiki | 人工导入 |
| Learnings | 错误模式 + 修复方案 | agent 自动积累 |
| Runtime context | 实时 schema 检查 | 每次调用动态 |
3.3 学习循环
Agent 跑 query → 遇到错误 → 诊断修复 → 保存 error pattern + fix → 下次碰到类似场景第一次就做对。
两个 agent 通过数据层异步协作：Engineer 创建 view → 录入 knowledge base → Analyst 下次搜索时自然发现。不需要”聊天”，共享不断丰富的数据层就够了。
“Query 100 is better than query 1, not because the model improved, but because the data layer got better.”
3.4 Runtime 动态组装 Instructions
系统指令从 table metadata + business rules 动态生成，不写死在代码里。Schema 变了 → agent 行为自动跟进，不用重新部署。等于把 instructions 也当数据管理，而不是代码。
3.5 操作三级审批
| 级别 | 操作类型 | 审批 |
|---|---|---|
| 自由执行 | reads | 无需确认 |
| 用户确认 | writes | 需用户 approve |
| 管理员签字 | sensitive operations | 需 admin 签字 |
3.6 自动化安全评估
Eval suite 专门测 prompt injection 泄露凭证、破坏性 SQL、跨 schema 访问——每次部署跑一遍，持续验证安全边界。
四、原文 vs 中文转述差异
SenseAI 转述整体忠实，但有几处差异值得注意：
- 被弱化：论眼”coding agents lowered the barrier…“在原文是开场定调，转述里变成中间点缀
- 被弱化：Engineer 侧的 query-level guard 写域限制（原文有两层硬约束，转述只讲了第一层）
- 被弱化：操作三级审批的具体三档（转述只说”分级”）
- 被扩写：SenseAI 加了自己的比喻（赛车 + 防滑链、盖房子先挖地基）和第 10 节五点启示
- 完全没提：Ashpreet 是 Agno 创始人，Dash 是 Agno 旗舰 demo——文章是给自家框架打样
Discussion 补充（2026-04-12）
Takeaway 1：硬约束 vs 软约束判断框架
判断标准：agent 无人值守时做的操作（cron、后台 agent）必须用配置硬约束，不能靠 prompt。有人值守时（terminal 交互），soft constraint + permission 确认够用。
实证：2026-04-12 早上 AI 日报 cron 把通知发给了小虾的 TG 群组而非 CC 的——skill 自作主张选了错误的 target。通知目标应该是 cron 配置里写死的，不是 agent 运行时判断的。
Takeaway 2：“犯过的错”结构化存储
当前 memory 系统缺 Ashpreet 六层里的第 5
层（Learnings）。踩坑经验散落在日记、dev-patterns、procedures 里，没有
{场景, 错误, 根因, 修复}
的结构化存储。可以在现有信号驱动捕捉里增加一条路由：踩坑/错误 →
dev-patterns.md 专门段落或独立文件，让 agent
能从历史错误中系统性学习。