文章核心观点 - 构建生产级智能体软件，不应仅聚焦于优化单个智能体（Agent），而应采用系统工程思维，将整个系统视为产品[2] - 智能体软件本质上是普通软件，其业务逻辑由智能体驱动，接口从请求/响应变为多端流式传输，应运用成熟的软件工程方法进行构建[11] 五层系统架构框架 - 作者提出了一个构建生产级智能体软件的五层架构框架，覆盖从基础设施到智能体工程的完整路径[7] - 该框架包括：智能体工程、数据工程、安全工程、接口工程、基础设施工程[10] - 其核心洞察是，智能体软件95%的基础设施工程与传统服务相同，区别在于处理时间更长、响应为流式、且可能需支持主动式任务[31] 智能体工程层 - 该层负责智能体本身的逻辑与执行流程，包括模型选择、指令、工具配置、多智能体交接、上下文管理与可观测性[12] - 关键设计原则是行为应尽可能确定，在不确定处需确保可观测[10] - 在实战项目Dash中，该层被设计为一个团队：一个Leader负责路由，Analyst（分析师）和Engineer（工程师）两个专家分别负责查询与构建数据资产，权限通过工具配置实现硬约束，而非依赖提示词的软约束[12][13] - 系统指令为动态组装，基于表元数据和业务规则生成，使智能体行为能随数据变化而调整[14] 数据工程层 - 该层负责为智能体提供正确的决策上下文，核心是记忆、存储和知识库的管理[10][16] - 关键原则是使用数据库而非文件系统来管理数据[10] - Dash项目采用六层数据上下文系统来解决企业数据环境的复杂性，包括：表元数据、人工标注、查询模式、机构知识、学习记录、运行时上下文[17][19][20][21] - 数据基础设施的完善比优化提示词更为重要，第100次查询优于第1次，依靠的是数据层的改进而非模型进步[37] 安全工程层 - 安全是系统属性，不能仅通过提示词指令来实现，而应在系统层面构建[10][23] - 权限控制应在工具配置层面实现硬约束，例如通过只读的数据库连接来确保“只读”权限[26] - 需防范用户上下文泄漏，这属于数据泄露而非简单的程序错误[27] - Dash在生产环境中使用JWT认证和基于角色的访问控制（RBAC），并配备自动化的安全评估套件，持续验证安全边界[28] 接口工程层 - 该层需确保智能体在多种接入端（如REST API、Slack、Web界面、命令行）上，其认证、策略和访问控制保持一致[30] - 核心任务是统一多端身份和权限映射，防止不同入口行为不一致导致用户体验割裂[10][30] - Dash的做法是让所有接口表面调用同一套智能体、工具和知识库，仅在接口层完成身份映射[30] 基础设施工程层 - 该层95%的内容与运行传统服务无异，包括容器化、云部署和水平扩展[10][31] - 针对智能体的5%特殊性调整包括：增加负载均衡器超时以处理更长请求、支持服务器发送事件（SSE）或WebSocket以实现流式响应、以及支持定时任务以实现主动式智能体[31] - Dash采用极简的Python容器，通过Docker Compose进行本地开发，并使用标准ASGI服务器实现SSE流式传输[33] 学习循环设计 - Dash设计了自我学习循环：智能体执行查询→遇到错误→诊断修复→保存经验→提升后续查询成功率[36] - 这种设计使得智能体能力提升依赖于数据基础设施的完善和经验的积累，而非模型本身的迭代[37][38] - 智能体之间通过共享并不断丰富的知识库进行异步协作，比直接对话更为优雅高效[38] 系统思维的价值 - 从系统视角进行设计，能使各层级相互强化，避免因孤立决策产生连锁的约束反应[39][40] - 正确的系统设计决策会自动浮现，例如使用数据库进行数据管理，为安全层的权限隔离提供基础[39][40] - 构建智能体产品应先设计系统架构，而非先实现单个组件再修补后续问题[40][43]