系统工程:AI软件生态也要面临的问题
原文链接: https://x.com/ashpreetbedi/status/2041568919085854847

20世纪40年代初,贝尔实验室正在建设全国电话网络,这是当时世界上最复杂的系统。
数百万个交换机、电缆、继电器和操作员必须协同工作。
工程师们发现了一个将成为80年经验的教训:你不能通过优化单个组件来优化系统。
整体行为(呼叫路由、可靠性、容量、成本)来自于部件之间的相互作用。他们需要一个专注于组件之间相互作用的学科。
他们称之为系统工程。
Agent软件生态系统正在重复导致该学科产生的相同错误。
当前的利用工程浪潮会要求你使用文件系统进行存储和内存,然后尝试通过在数据库上构建虚拟文件系统来规避其限制。
它会要求你使用 bash 作为通用工具,然后强迫你进入每个请求的沙盒来处理安全问题。这些都是没有考虑系统整体而优化单个部分的症状。
而我们却在没有花一分钟时间来问这是否是正确方法的情况下就接受了它。
软件工程是系统工程
编码智能体降低了编写代码的门槛,但它们并没有降低生产软件的要求。
软件工程始终是系统工程,如果你正在构建智能体软件,你的系统需要连接这五个层次:
1. 智能体工程 : 你的智能体或多智能体逻辑和执行流程。
模型、系统指令、工具配置、交接、上下文管理、可观察性。这是你定义智能体做什么、如何运行以及如何响应的地方。你的智能体行为应在可能的情况下是确定的,在不可能的情况下是可观察的。
2. 数据工程 : 你的智能体只有在能够访问的上下文中才表现良好,而上下文本质上就是数据。记忆、存储、知识:所有这些都应通过数据工程原则进行管理。这意味着精心设计的模式、结构化查询、用于快速读写数据库、对象存储用于长期存储,以及保持你的知识和记忆更新的管道。这些模式已经存在了几十年。使用它们。
3. 安全工程 : 身份验证、基于角色的访问控制、治理、数据隔离、审计追踪。
您的智能体的功能由其工具定义,而这些工具应使用基于 JWT 的权限进行范围限定。只读访问不是提示指令,而是工具配置。操作应具有审批层级:读取操作可以自由执行,写入操作需要用户审批,敏感操作需要管理员签字确认。大多数操作都应被记录,并且在整个产品生命周期内可查询。
请务必隔离请求。一个用户的环境信息泄露到另一个用户那里是数据泄露,而不是错误。这会带来严重后果,并且有法律保护用户数据。因此,在共享沙盒上使用文件系统支持的内存可能不是个好主意。
4. 接口工程 : 用户和其他智能体如何与您的智能体交互。
REST 应用程序接口,Slack,模型上下文协议服务器,终端。在旧时代,你只有一个应用程序接口和一个客户端。现在你有多个界面,每个界面都有自己的身份系统。一个 Slack 用户 ID 不是你产品的用户 ID。一个 MCP 客户端以另一个智能体的身份进行身份验证不是人类用户。界面工程是确保你的认证、策略和访问控制在你智能体可访问的每个界面上保持一致。
5. 基础设施工程 : 如何运行和扩展你的软件。容器,云部署,水平扩展。通常称为 DevOps。
好消息:95%的这部分内容与运行任何其他服务相同。重用现有模式,它们会对你很有帮助。
不同的 5%:智能体请求需要更长时间(增加你的负载均衡器超时),响应是流式的(计划使用 SSE 或 WebSockets),最好的智能体是主动的(计划任务,后台执行)。这些都不是新的。
AI 工程师的关键在于认识到智能体软件其实就是普通软件,只是将业务逻辑替换为智能体,并且接口从请求/响应转变为跨多个界面的流式输出。
系统工程是使这些部分协同工作的学科,也是构建有效智能体软件的关键。
当你从系统角度审视你的软件时,正确的决策会变得显而易见,你也不再争论模型上下文协议(MCP)与命令行接口(CLI)。
你为智能体提供范围明确的工具,而不是无限制的 bash 访问权限。
你将会话、记忆和知识存储在数据库中,而不是文件中。
当你孤立地设计一个层次时,你会继承那些在整个系统中级联的约束,并且浪费时间和资源去修补这些约束。当你从系统的角度进行设计时,每一层都会相互强化。
实践中的系统工程
我不能做出如此大的声明而不给你可运行的代码。
Dash 是一个开源的自学习数据智能体 –》https://github.com/agno-agi/dash
你可以用普通英语向它提问,它会编写 SQL,运行它,并告诉你数字的含义。简单到可以克隆和适配。真实到足以演示所有五个层次。
dash 中每一层的工作原理如下:
智能体工程
Dash 是一个由智能体组成的团队。领导者将请求路由到两个专家:一个分析师用于查询数据(只读),一个工程师用于构建计算资产,如视图和汇总表。每个专家都连接到不同功能类型的相同工具。分析师的 SQL 工具连接到只读数据库引擎。工程师的 SQL 工具连接到可写入的引擎,其作用域限制在一个模式中。相同的接口,不同的权限,由配置决定,而不是提示。指令在运行时从表元数据和业务规则中组装。
数据工程
六层上下文,以及学习工具。
原始 LLMs 编写 SQL 很快就会遇到瓶颈:模式缺乏意义,类型具有误导性,部落知识缺失,没有办法从错误中学习。
Dash 通过六层基于上下文来解决此问题:
-
表元数据(模式、列、关系)
-
人类注释(指标、定义、业务规则)
-
查询模式(已知有效的 SQL)
-
机构知识(文档、维基)
-
学习成果(错误模式和发现的解决方案)
-
运行时上下文(实时模式检查)
这些层为两个系统提供支持:
-
第一个是精选知识:表架构、经过验证的查询和业务规则加载到 PostgreSQL 中。
-
第二个是发现的学习成果:智能体在遇到问题时保存的错误模式及其解决方案,并在未来的查询中调用。
学习循环很简单:
智能体运行一个查询,得到一个类型错误,诊断并修复它,然后保存。
下次它看到相似的列时,就能第一次就正确处理。当工程师创建新视图时,它会将模式示例查询记录到知识库中。分析师在下次搜索中发现了它,并开始使用。
第100个查询比第1个查询更好,不是因为模型改进了,而是因为数据层变好了。
安全工程
由系统强制执行,而不是提示。
生产中的 Dash 使用 RBAC 与 JWT 验证。每个查询都限定在user_id范围内。一个评测套件直接测试这些边界:它提示智能体泄露凭证,执行破坏性 SQL,跨越模式边界,然后验证它们不能这样做。
安全性是一个跨层测试的系统属性。分析师的只读访问是 PostgreSQL 连接参数。数据库本身拒绝写入,无论模型生成什么。工程师可以写入,但只能写入单个模式:查询级别的保护阻止任何针对源数据的操作。
接口工程
Dash 可以作为 REST API、Slack 机器人、Web UI 和 CLI 使用。每个界面处理身份的方式不同:Slack 将线程时间戳映射到会话,API 在生产环境中使用 JWT 令牌。但所有四个都访问相同的智能体、相同的工具和相同的知识。
您的认证和访问控制需要在每个界面上保持一致,因为智能体不知道它正在从哪个界面被调用。
基础设施工程
最小的 Python 容器。使用 Docker compose 进行本地开发。部署到您选择的云。通过标准 ASGI 服务器通过 SSE 进行流式传输。95%的内容与其他任何服务相同。5%的不同之处(更长的超时、流式传输、计划任务)使用标准工具处理。
您可以克隆它,运行docker compose up,即可拥有整个系统。
一条命令,五层架构,依靠系统工程打造出成功产品。
项目地址:https://github.com/agno-agi/dash
夜雨聆风