系统工程：构建真正可用的 Agentic 软件

系统工程：构建真正可用的 Agentic 软件 系统工程：构建真正可用的 Agentic 软件 Modified April 8 原帖链接：https://x.com/ashpreetbedi/status/2041568919085854847 在 1940 年代早期，贝尔实验室正在建设全国电话网络，那是当时世界上最复杂的技术系统。数百万个交换机、电缆、继电器和接线员必须协同工作。工程师们发现了一件后来成为 80 年经验教训的事：你无法通过优化单个组件来优化整个系统。系统整体的行为（呼叫路由、可靠性、容量、成本）取决于各部分如何相互作用。他们需要一门专注于组件之间交互的学科。 他们称之为系统工程。 软件工程即系统工程 Agentic software 生态系统正在重复当年催生这门学科时犯下的同样错误。当前这波 harness engineering 会让你用文件系统来做存储和记忆，然后再试图通过在数据库之上构建一个虚拟文件系统来绕开它的限制。它会让你把 bash 当作通用工具，然后为了安全再强迫你进入按请求隔离的 sandbox。这些都是在没有从系统整体角度考虑的前提下，只优化某个局部所产生的症状。而我们正在照单全收，却没有花一分钟去问：这真的是正确的方法吗？ Coding agents 确实降低了写代码的门槛，但它们并没有降低生产级软件的要求。软件工程本质上一直都是系统工程；如果你正在构建 agentic software，那么你的系统就需要打通这五层： 1. Agent Engineering：你的 agent 或 multi agent 逻辑与执行流。 Model、system instructions、tool configurations、handoffs、context management、observability。这里定义的是你的 agent 做什么、如何运行，以及如何响应。你的 agent 行为在可能的地方应当是确定性的，在不能确定的地方应当是可观测的。 2. Data Engineering：你的 agent 能力上限取决于它可以访问的上下文，而上下文本质上就是数据。Memory、storage、knowledge，都应该用数据工程原则来管理。这意味着设计良好的 schema、结构化查询、适合快速读写的数据库、适合长期存储的对象存储，以及让知识和记忆始终保持最新的 pipeline。这些模式已经存在几十年了。拿来用。 3. Security Engineering：Auth、RBAC、governance、data isolation、audit trails。 你的 agent 能做什么，是由它的工具决定的，而这些工具应该通过 JWT 支撑的权限来进行作用域控制。只读访问不是一条 prompt instruction，它是一项 tool configuration。操作应当有审批分级：读取可以自由执行，写入需要用户批准，敏感操作需要管理员签字。大多数操作都应该被记录，并且在产品生命周期内可查询。 另外，请务必隔离请求。一个用户的上下文泄漏到另一个用户那里，这不是 bug，而是数据泄露。它会带来严重后果，而且有法律专门保护用户数据。所以，在共享 sandbox 上用文件系统支撑 memory，也许并不是个好主意。 4. Interface Engineering：用户和其他 agents 如何接入你的 agent。 REST API、Slack、MCP server、terminal。在旧世界里，你只有一个 API 和一个 client。现在你有多个 surface，而每个 surface 都有自己的 identity system。Slack 用户 ID 不是你产品里的用户 ID。一个以另一个 agent 身份认证的 MCP client 也不是人类用户。Interface engineering 的任务，就是确保无论你的 agent 从哪个 surface 被访问，你的 auth、policy 和 access control 都能保持一致。 5. Infrastructure Engineering：你如何运行和扩展你的软件。Containers、cloud deployment、horizontal scaling。通常这被称作 DevOps。 好消息是：其中 95% 和运行其他任何服务完全一样。复用现有模式，它们会很好地服务你。那 5% 的差异在于：agent 请求耗时更长（提高 load balancer timeout），响应是流式的（为 SSE 或 WebSockets 做规划），而最好的 agents 是主动型的（scheduled tasks、background execution）。这些都不新鲜。 AI 工程师的关键认知升级在于：agentic software 本质上就是普通软件，只不过业务逻辑被 agents 替代了，而接口从 request/response 变成了跨多个 surface 的流式交互。 系统工程，就是让这些部分协同工作的学科，也是构建真正可用的 agentic software 的关键。 当你从系统视角看自己的软件时，正确决策会变得非常明显，你也就不会再争论 MCP 还是 CLI。你会给 agent 配置好作用域明确的工具，而不是毫无限制的 bash 访问。你会把 session、memory 和 knowledge 存进数据库，而不是文件。 当你孤立地设计某一层时，你会继承那些沿着系统其余部分层层传导的约束，并浪费时间和资源去修补这些约束。当你从系统视角来设计时，每一层都会增强其他层。 实践中的系统工程 我不能提出这么大的论断，却不给你可运行的代码。 Dash is an open source, self learning data agent. 你可以用自然语言向它提问，它会写 SQL、执行 SQL，并告诉你数字意味着什么。简单到足以 clone 和改造，真实到足以演示这五层是如何工作的。 下面是 dash 中每一层的工作方式： 智能体工程 Dash 是一个 agent 团队。一个 Leader 会把请求路由给两个 specialist：一个查询数据的 Analyst（只读），以及一个构建计算资产（如 views 和 summary tables）的 Engineer。每个 specialist 拿到的是相同类型的工具，但这些工具被接上了不同能力。Analyst 的 SQL 工具连接到只读数据库引擎。Engineer 的 SQL 工具连接到限定在单一 schema 下的可写引擎。相同接口，不同权限，权限由配置决定，而不是由 prompt 决定。Instructions 会在运行时根据表元数据和业务规则动态组装。 数据工程 六层上下文，以及用于学习的工具。 原始 LLM 在写 SQL 时很快就会撞墙：schema 缺乏语义、类型信息会误导、部落知识缺失，也没有办法从错误中学习。Dash 通过六层扎实的上下文来解决这个问题： • 表元数据（schema、columns、relationships） • 人工注释（metrics、definitions、business rules） • 查询模式（已知可用的 SQL） • 机构知识（docs、wikis） • 经验（错误模式与已发现修复） • 运行时上下文（实时 schema inspection） 这六层会输入给两个系统： • 第一个是 curated knowledge：表 schema、已验证查询和 business rules，被加载进 PostgreSQL。 • 第二个是 discovered learnings：当 agent 遇到问题时，会把错误模式与修复方法保存下来，并在未来查询中召回。 这个学习循环非常简单：agent 运行查询，得到类型错误，诊断修复方式，然后把它保存下来。下一次看到类似的列时，它第一次就能做对。而当 Engineer 创建出一个新的 view 时，它会把 schema 和示例查询记录进知识库。Analyst 会在下一次搜索时发现它，并开始使用它。第 100 次查询会比第 1 次更好，不是因为模型进步了，而是因为数据层进步了。 安全工程 由系统强制，而不是由 prompt 强制。 生产环境中的 Dash 使用了带 JWT 校验的 RBAC。每个查询都会被限定在 user id 作用域内。一套 eval 测试会直接测试这些边界：它会提示 agents 泄露凭证、执行破坏性 SQL、跨 schema 操作，然后验证它们做不到。 安全是一个跨层测试的系统属性。Analyst 的只读权限是一个 PostgreSQL 连接参数。无论模型生成什么，数据库本身都会拒绝写操作。Engineer 可以写，但只能写入单一 schema：一个查询级 guard 会阻止任何针对源数据的操作。 界面工程 Dash 可以通过 REST API、Slack bot、web UI 和 CLI 提供服务。每个 surface 处理 identity 的方式都不同：Slack 会把 thread timestamp 映射到 session，API 在生产环境里使用 JWT token。但这四个 surface 打到的都是同一套 agents、同一套 tools、同一套 knowledge。 你的 auth 和 access control 必须在每个 surface 上都成立，因为 agent 并不知道自己是从哪个 surface 被调用的。 基础设施工程 极简 python container。用 Docker compose 做本地开发。部署到你选择的云上。通过标准 ASGI server 用 SSE 进行流式传输。那 95% 和其他服务一致的部分，真的就是一致的。那 5% 不同的部分（更长 timeout、流式输出、定时任务）也都由标准工具来处理。 你可以 clone 它，运行 docker compose up，然后得到整个系统。 一个命令，五层结构，一个真正可运行的产品，这都归功于系统工程。 参考链接如下：https://github.com/agno agi/dash 原帖链接：https://x.com/ashpreetbedi/status/2041568919085854847 原帖链接：https://x.com/ashpreetbedi/status/2041568919085854847 在 1940 年代早期，贝尔实验室正在建设全国电话网络，那是当时世界上最复杂的技术系统。数百万个交换机、电缆、继电器和接线员必须协同工作。工程师们发现了一件后来成为 80 年经验教训的事：你无法通过优化单个组件来优化整个系统。系统整体的行为（呼叫路由、可靠性、容量、成本）取决于各部分如何相互作用。他们需要一门专注于组件之间交互的学科。 他们称之为系统工程。 软件工程即系统工程 Agentic software 生态系统正在重复当年催生这门学科时犯下的同样错误。当前这波 harness engineering 会让你用文件系统来做存储和记忆，然后再试图通过在数据库之上构建一个虚拟文件系统来绕开它的限制。它会让你把 bash 当作通用工具，然后为了安全再强迫你进入按请求隔离的 sandbox。这些都是在没有从系统整体角度考虑的前提下，只优化某个局部所产生的症状。而我们正在照单全收，却没有花一分钟去问：这真的是正确的方法吗？ Coding agents 确实降低了写代码的门槛，但它们并没有降低生产级软件的要求。软件工程本质上一直都是系统工程；如果你正在构建 agentic software，那么你的系统就需要打通这五层： 1. Agent Engineering：你的 agent 或 multi agent 逻辑与执行流。 Model、system instructions、tool configurations、handoffs、context management、observability。这里定义的是你的 agent 做什么、如何运行，以及如何响应。你的 agent 行为在可能的地方应当是确定性的，在不能确定的地方应当是可观测的。 2. Data Engineering：你的 agent 能力上限取决于它可以访问的上下文，而上下文本质上就是数据。Memory、storage、knowledge，都应该用数据工程原则来管理。这意味着设计良好的 schema、结构化查询、适合快速读写的数据库、适合长期存储的对象存储，以及让知识和记忆始终保持最新的 pipeline。这些模式已经存在几十年了。拿来用。 3. Security Engineering：Auth、RBAC、governance、data isolation、audit trails。 你的 agent 能做什么，是由它的工具决定的，而这些工具应该通过 JWT 支撑的权限来进行作用域控制。只读访问不是一条 prompt instruction，它是一项 tool configuration。操作应当有审批分级：读取可以自由执行，写入需要用户批准，敏感操作需要管理员签字。大多数操作都应该被记录，并且在产品生命周期内可查询。 另外，请务必隔离请求。一个用户的上下文泄漏到另一个用户那里，这不是 bug，而是数据泄露。它会带来严重后果，而且有法律专门保护用户数据。所以，在共享 sandbox 上用文件系统支撑 memory，也许并不是个好主意。 4. Interface Engineering：用户和其他 agents 如何接入你的 agent。 REST API、Slack、MCP server、terminal。在旧世界里，你只有一个 API 和一个 client。现在你有多个 surface，而每个 surface 都有自己的 identity system。Slack 用户 ID 不是你产品里的用户 ID。一个以另一个 agent 身份认证的 MCP client 也不是人类用户。Interface engineering 的任务，就是确保无论你的 agent 从哪个 surface 被访问，你的 auth、policy 和 access control 都能保持一致。 5. Infrastructure Engineering：你如何运行和扩展你的软件。Containers、cloud deployment、horizontal scaling。通常这被称作 DevOps。 好消息是：其中 95% 和运行其他任何服务完全一样。复用现有模式，它们会很好地服务你。那 5% 的差异在于：agent 请求耗时更长（提高 load balancer timeout），响应是流式的（为 SSE 或 WebSockets 做规划），而最好的 agents 是主动型的（scheduled tasks、background execution）。这些都不新鲜。 AI 工程师的关键认知升级在于：agentic software 本质上就是普通软件，只不过业务逻辑被 agents 替代了，而接口从 request/response 变成了跨多个 surface 的流式交互。 系统工程，就是让这些部分协同工作的学科，也是构建真正可用的 agentic software 的关键。 当你从系统视角看自己的软件时，正确决策会变得非常明显，你也就不会再争论 MCP 还是 CLI。你会给 agent 配置好作用域明确的工具，而不是毫无限制的 bash 访问。你会把 session、memory 和 knowledge 存进数据库，而不是文件。 当你孤立地设计某一层时，你会继承那些沿着系统其余部分层层传导的约束，并浪费时间和资源去修补这些约束。当你从系统视角来设计时，每一层都会增强其他层。 实践中的系统工程 我不能提出这么大的论断，却不给你可运行的代码。 Dash is an open source, self learning data agent. 你可以用自然语言向它提问，它会写 SQL、执行 SQL，并告诉你数字意味着什么。简单到足以 clone 和改造，真实到足以演示这五层是如何工作的。 Dash is an open source, self learning data agent 下面是 dash 中每一层的工作方式： 智能体工程 Dash 是一个 agent 团队。一个 Leader 会把请求路由给两个 specialist：一个查询数据的 Analyst（只读），以及一个构建计算资产（如 views 和 summary tables）的 Engineer。每个 specialist 拿到的是相同类型的工具，但这些工具被接上了不同能力。Analyst 的 SQL 工具连接到只读数据库引擎。Engineer 的 SQL 工具连接到限定在单一 schema 下的可写引擎。相同接口，不同权限，权限由配置决定，而不是由 prompt 决定。Instructions 会在运行时根据表元数据和业务规则动态组装。 数据工程 六层上下文，以及用于学习的工具。 原始 LLM 在写 SQL 时很快就会撞墙：schema 缺乏语义、类型信息会误导、部落知识缺失，也没有办法从错误中学习。Dash 通过六层扎实的上下文来解决这个问题： • 表元数据（schema、columns、relationships） • 人工注释（metrics、definitions、business rules） • 查询模式（已知可用的 SQL） • 机构知识（docs、wikis） • 经验（错误模式与已发现修复） • 运行时上下文（实时 schema inspection） 这六层会输入给两个系统： • 第一个是 curated knowledge：表 schema、已验证查询和 business rules，被加载进 PostgreSQL。 • 第二个是 discovered learnings：当 agent 遇到问题时，会把错误模式与修复方法保存下来，并在未来查询中召回。 这个学习循环非常简单：agent 运行查询，得到类型错误，诊断修复方式，然后把它保存下来。下一次看到类似的列时，它第一次就能做对。而当 Engineer 创建出一个新的 view 时，它会把 schema 和示例查询记录进知识库。Analyst 会在下一次搜索时发现它，并开始使用它。第 100 次查询会比第 1 次更好，不是因为模型进步了，而是因为数据层进步了。 安全工程 由系统强制，而不是由 prompt 强制。 生产环境中的 Dash 使用了带 JWT 校验的 RBAC。每个查询都会被限定在 user id 作用域内。一套 eval 测试会直接测试这些边界：它会提示 agents 泄露凭证、执行破坏性 SQL、跨 schema 操作，然后验证它们做不到。 安全是一个跨层测试的系统属性。Analyst 的只读权限是一个 PostgreSQL 连接参数。无论模型生成什么，数据库本身都会拒绝写操作。Engineer 可以写，但只能写入单一 schema：一个查询级 guard 会阻止任何针对源数据的操作。 界面工程 Dash 可以通过 REST API、Slack bot、web UI 和 CLI 提供服务。每个 surface 处理 identity 的方式都不同：Slack 会把 thread timestamp 映射到 session，API 在生产环境里使用 JWT token。但这四个 surface 打到的都是同一套 agents、同一套 tools、同一套 knowledge。 你的 auth 和 access control 必须在每个 surface 上都成立，因为 agent 并不知道自己是从哪个 surface 被调用的。 基础设施工程 极简 python container。用 Docker compose 做本地开发。部署到你选择的云上。通过标准 ASGI server 用 SSE 进行流式传输。那 95% 和其他服务一致的部分，真的就是一致的。那 5% 不同的部分（更长 timeout、流式输出、定时任务）也都由标准工具来处理。 你可以 clone 它，运行 docker compose up，然后得到整个系统。 一个命令，五层结构，一个真正可运行的产品，这都归功于系统工程。 参考链接如下：https://github.com/agno agi/dash