Agno 创始人 Ashpreet Bedi 发了一篇长文，核心观点只有一句话：别再只优化你的 Agent 了，整个系统才是产品。

他提出了一个五层架构框架，从智能体工程到基础设施工程，覆盖了构建生产级智能体软件的完整路径。更重要的是，他用自己的开源项目 Dash（一个数据分析智能体）作为实战案例，把每一层都写成了可运行的代码。

这篇文章在 X 上获得了 1.58 万次浏览、282 个赞、37 次转发。我仔细读了一遍，觉得这是目前关于智能体工程最务实的一篇文章。

01 贝尔实验室的教训

:::

1940 年代初，贝尔实验室在建造美国国家电话网络——当时世界上最复杂的技术系统。数百万个交换机、电缆、继电器和接线员必须协同工作。工程师们发现了一个后来被验证了 80 年的教训：你无法通过优化单个组件来优化整个系统。

整个系统的行为——路由、可靠性、容量、成本——取决于各部分之间的交互方式，而不是单个部分本身的性能。他们需要一门专注于组件间交互的学科。

他们把这门学科叫做系统工程。

Ashpreet 认为，今天的智能体软件生态正在重蹈覆辙。当下流行的做法是：用文件系统做存储和记忆，然后发现不够用，再在数据库上搭一层虚拟文件系统；用 bash 作为通用工具，然后为了安全再加一层沙箱隔离。

这就好比你买了一辆赛车，却发现它在泥地里跑不动。于是你给轮胎套上防滑链，在引擎盖上加防水罩——但这只是缝缝补补，真正的问题在于你从一开始就选错了底层架构。

02 五层架构

:::

Ashpreet 提出，构建生产级智能体软件需要横跨五个工程层：

智能体软件的五层系统架构：从基础设施到智能体工程

层级	核心职责	关键原则
智能体工程	模型、指令、工具、交接、上下文	行为尽可能确定，不确定处可观测
数据工程	记忆、存储、知识库	用数据库，别用文件系统
安全工程	认证、RBAC、审计、数据隔离	安全是系统属性，不是提示词指令
接口工程	REST API、Slack、MCP、终端	多端统一身份和权限
基础设施工程	容器、部署、水平扩展	95% 和传统服务一样

他的核心洞察是：智能体软件就是普通软件，只不过业务逻辑换成了智能体，接口从请求/响应变成了多端流式传输。

换句话说，别把智能体当成什么全新的物种。它就是软件。用软件工程的方式去构建它。

我自己在实际开发中也深有体会。最初做智能体项目时，会不自觉地把所有精力放在优化提示词和调模型上，觉得模型越强大、提示词越精巧，产品就越好。但上线之后才发现，真正决定用户体验的往往是那些「无聊」的工程问题：数据持久化是否靠谱、权限有没有漏洞、不同入口的行为是否一致。Ashpreet 这个五层框架，把这些容易被忽视的层面系统化了。

03 智能体工程

:::

第一层是智能体本身的逻辑和执行流程：模型选择、系统指令、工具配置、多智能体交接、上下文管理、可观测性。

在他的实战项目 Dash 中，这一层被设计成一个团队：一个 Leader 负责路由请求，两个专家——Analyst 负责查询数据（只读），Engineer 负责构建数据资产（如创建视图和汇总表）。每个专家拥有相同类型的工具，但权限不同：Analyst 的 SQL 工具连接只读数据库引擎，Engineer 的 SQL 工具连接可写引擎，且仅限单个 schema。

关键词是：相同接口，不同权限，由配置决定，而非提示词。

这个设计选择很关键。很多团队做多智能体时，权限区分是靠在系统提示词里写「你只能做 X」。但提示词是软约束——模型被诱导后完全可能忽略。而 Dash 把权限做成了硬约束：Analyst 连接的数据库引擎本身就不支持写操作，不管模型输出什么 SQL，数据库层就会拒绝。这才是工程级别的安全边界。

系统指令也是运行时动态组装的——从表元数据和业务规则中生成，而不是写死在代码里。这意味着当你的数据变了，智能体的行为也会随之调整。

编程智能体降低了写代码的门槛，但并没有降低生产级软件的要求。这句话值得反复读。

04 数据工程

:::

你的智能体只有拿到正确的上下文才能做出正确的决策，而上下文的本质就是数据。

裸模型写 SQL 很快就会碰壁。你可能觉得让大语言模型写 SQL 很简单——不就是自然语言转结构化查询吗？但实际工程中，一个真实的企业数据库有几百张表，列名可能是缩写（比如 cust_addr_ln1），类型可能是误导性的（用 VARCHAR 存日期），还有大量只存在于老员工脑子里的业务规则（比如 status=3 其实表示「已退款」）。没有这些上下文，模型写出来的 SQL 看起来语法正确，但查出来的数据可能完全不对。

Dash 用六层上下文来系统性地解决这个问题：

Dash 的六层数据上下文：从表元数据到运行时上下文

层级	内容
表元数据	schema、列、关系
人工标注	指标定义、业务规则
查询模式	已验证的 SQL 查询
机构知识	文档、wiki、内部资料
学习记录	错误模式与修复方案
运行时上下文	实时 schema 检查

这六层数据分别供给两个系统：一是专家经验（表 schema、已验证查询、业务规则，存入 PostgreSQL）；二是动态学习（由智能体在运行中自动积累的错误模式和修复方案）。

记忆、存储、知识库——所有这些都应该用数据工程的原则来管理。这意味着精心设计的 schema、结构化查询、用数据库做快速读写、用对象存储做长期存储、用数据管道保持知识库更新。

这些模式已经存在几十年了。直接用就好。

05 安全工程

:::

这一层可能是最容易被忽视的，也是最危险的。

安全工程的三重防线：JWT 认证、访问控制列表、审计日志

Ashpreet 的观点非常明确：安全是系统属性，不是提示词指令。

他举了一个很好的例子：「只读权限」不是在系统提示词里写一句「你只能读取数据」就完了。它应该是工具配置层面的约束——数据库连接本身就是只读的，无论模型生成什么 SQL，数据库都会拒绝写操作。

操作也应该分级：读取操作自由执行，写入操作需要用户确认，敏感操作需要管理员审批。大部分操作应该被记录并且可查询。

还有一句话我觉得特别重要：

一个用户的上下文泄漏到另一个用户的请求里，这不是 bug，这是数据泄露。这是有法律后果的。所以，在共享沙箱上用文件系统做记忆，可能不是个好主意。

在 Dash 的生产环境中，他们用 JWT 验证做 RBAC，每条查询都限定在 user_id 范围内。他们还有一套评估套件，专门测试安全边界：提示智能体泄露凭证、执行破坏性 SQL、跨 schema 访问——然后验证它们全都失败。

注意，这里的安全测试不是手动的，而是自动化的评估套件。这意味着每次部署都可以跑一遍，确保安全边界没有被改动打破。这才是「安全是系统属性」的完整含义——不只是设计时考虑安全，而是持续验证安全。

06 接口工程

:::

一个智能体，多个入口：REST API、Slack、命令行、浏览器统一接入

传统软件的世界很简单：一个 API，一个客户端。但智能体时代，你的 Agent 可能同时被 REST API、Slack 机器人、Web 界面和命令行调用。每个表面都有自己的身份系统。

Slack 用户 ID 不等于你产品的用户 ID。一个通过 MCP 协议认证的智能体客户端也不是人类用户。接口工程的核心任务是：确保你的认证、策略和访问控制在每一个接入端上都保持一致。

Dash 的做法是：REST API、Slack 机器人、Web 界面和 CLI 四个表面，都调用同一套智能体、同一套工具、同一个知识库。身份映射在接口层完成——Slack 用线程时间戳映射会话，API 用 JWT。但底层完全一致。

这里有一个容易踩的坑：很多团队会为每个接口单独写一套集成逻辑，时间一长，各个入口的行为就开始分叉。用户从 Slack 问的问题得到一个答案，从 API 问同样的问题得到另一个答案。这不是 bug，但对用户来说体验就是不一致。Dash 的做法从架构层面杜绝了这个问题。

07 基础设施

:::

好消息：95% 的基础设施工程和运行其他任何服务完全一样。容器化、云部署、水平扩展——这些都是成熟的技术栈，照搬就行。

剩下 5% 的区别在于：智能体请求处理时间更长（需要增加负载均衡器超时）、响应是流式的（需要 SSE 或 WebSocket）、最好的智能体是主动式的（需要定时任务和后台执行）。

这些都不是什么新东西。

Dash 的做法是：一个极简的 Python 容器，用 Docker Compose 做本地开发，通过标准 ASGI 服务器实现 SSE 流式传输。你可以克隆仓库，运行 docker compose up，五层架构、一个完整产品，一行命令全部跑起来。

我觉得这个态度本身就值得学习：与其争论架构该怎么做，不如写出来让人跑。代码比幻灯片更有说服力。

08 学习循环

:::

Dash 中最让我眼前一亮的设计是它的学习循环。

Dash 的自我学习循环：执行查询 → 遇到错误 → 诊断修复 → 保存经验 → 下次查询成功

过程很简洁：智能体执行一条查询，遇到类型错误，诊断出修复方案，保存下来。下次碰到类似的列，它第一次就能写对。而当 Engineer 创建了一个新视图，它会自动把 schema 和示例查询存入知识库。Analyst 在下次搜索时就能发现并开始使用这个新视图。

第 100 次查询比第 1 次好，不是因为模型进步了，而是因为数据层变好了。

这个设计思路值得所有在做智能体产品的团队学习。很多人花大量时间在调提示词上，其实真正该投入的是数据基础设施——让你的智能体有能力从自己的错误中学习。

而且注意，这里的两个专家智能体之间也通过数据层形成了协作闭环：Engineer 创建新视图并录入知识库，Analyst 在后续查询中自动发现并调用这些新视图。这种智能体之间通过共享知识库进行异步协作的模式，比直接的智能体对话要优雅得多——两个智能体不需要「聊天」，只需要共享一个不断丰富的数据层。

09 系统视角

:::

Ashpreet 总结了一个很精辟的判断标准：

当你从系统视角审视你的软件时，正确的决策会自动浮现——你不会再纠结「用 MCP 还是 CLI」这种问题。你会给智能体提供范围明确的工具，而不是无限制的 bash 访问。你会把会话、记忆和知识存进数据库，而不是文件。

这段话的力量在于：当你在一个层面做出孤立的设计决策时，你会引入约束，这些约束会像连锁反应一样传导到系统的其他部分。然后你就得花时间和资源去修补这些约束带来的副作用。

但如果你从系统的视角去设计，每一层都会强化其他层。比如：数据层用了数据库，安全层就可以在数据库连接级别做权限隔离；接口层统一了身份映射，安全策略就可以在所有表面一致执行；基础设施用了容器化，部署和测试就可以做到一行命令完成。

这让我想到一个类比：就像盖房子，你不能先盖好屋顶，再想地基怎么办。很多团队做智能体产品就是这个状态——先把 Agent 跑起来，安全？之后再说。数据？先写文件吧。接口？先做一个 API。等到要上线的时候才发现，这些层之间的裂缝已经大到无法弥合。

10 对我们意味着什么

:::

Ashpreet 这篇文章最大的贡献，不是告诉你该怎么做，而是改变了你看问题的方式。

我和团队讨论后，总结了五点核心启示：

1. **智能体是软件，不是魔法。**编程智能体降低了写代码的门槛，但没有降低软件工程的要求。模型只是业务逻辑层，系统才是产品。

2. 安全不是事后补丁。「只读」应该是数据库连接参数，不是提示词里的一句话。跨用户数据泄露是法律问题，不是 bug。

3. **数据基础设施比提示词工程重要。**第 100 次查询比第 1 次好，靠的不是更好的模型，而是更好的数据层。把精力投入到让智能体能自我学习的基础设施上。

4. **成熟的工程模式已经存在了几十年。**数据库、RBAC、容器化、流式传输——这些都不是新发明。智能体软件只是把它们重新组合了。

5. **先设计系统，再写代码。**孤立设计一个层，约束会像连锁反应一样传导。从系统视角出发，每一层都会强化其他层。

当然了，这篇文章也有它的局限。Dash 是一个数据分析场景，相对明确和可控。更复杂的多智能体协作场景——比如自主编程、自主交易——面临的系统工程挑战可能远比五层架构更复杂：智能体之间的信任边界如何划定？跨智能体的事务如何保证一致性？失败时如何做优雅降级？这些问题 Ashpreet 没有展开，但他提供的系统思维框架，对审视任何场景都是一个好的起点。

贝尔实验室 80 年前就发现了：你无法通过优化单个组件来优化整个系统。这条规律，在智能体时代依然成立。如果你正在做智能体产品，建议把 Dash 的仓库克隆下来仔细看一遍——不是为了抄代码，而是为了看看一个从系统视角出发设计的产品，和你手头那个从单点优化出发搭建的产品，到底差在哪里。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】