1940年代，Bell Labs正在建设彼时世界上最复杂的系统——国家电话网。数百万个开关、电缆、继电器和操作员必须协同工作。工程师们发现了一个被验证了80年的教训：你无法通过优化单个组件来优化系统。 整个系统的行为（呼叫路由、可靠性、容量、成本）是从各部件如何交互中涌现出来的。

Agentic软件生态正在重复同样的错误。当前的harness工程要求你用文件系统做存储和memory，然后用数据库构建虚拟化文件系统来绕过限制；要求你用bash作为通用工具，然后用per-request沙箱来处理安全问题——这些都是优化局部而忽视整体的典型症状。

软件工程始终是系统工程。构建Agentic软件，你的系统需要贯通以下五个层面：

一、Agent Engineering

Agent或多Agent的逻辑与执行流。包括：模型、系统指令、工具配置、交接策略、上下文管理、可观测性。Agent的行为应该尽可能保持确定性，在做不到的地方保持可观测性。

二、Data Engineering

Agent的质量取决于它能访问的上下文，而上下文本质上是数据。Memory、存储、知识管理都应该遵循数据工程原则：设计良好的Schema、结构化查询、用于快速读写的数据库、用于长期存储的对象存储、以及保持知识和memory更新的数据管道。这些模式已经存在几十年了，直接用。

三、Security Engineering

Auth、RBAC、治理、审计。

Agent的能力由其工具定义，工具应该用JWT-backed权限来限定作用域。只读访问不是一条prompt指令，而是一个工具配置。 操作应该有审批层级：读取自由执行、写入需要用户审批、敏感操作需要管理员签署。大多数操作应该被记录并在产品生命周期内可查询。

更重要的是：隔离请求。用户间的上下文泄露是数据泄露，不是bug。 文件系统backed memory加上共享沙箱，可能不是好主意。

四、Interface Engineering

用户和其他Agent如何触达你的Agent。REST API、Slack、MCP Server、Terminal——每个表面都有各自的身份系统。Slack用户ID不是产品用户ID，MCP客户端认证的身份不是人类用户。Interface工程要确保你的auth、策略和访问控制在每一个可触达Agent的表面上保持一致。

五、Infrastructure Engineering

如何运行和扩展软件。容器化、云部署、水平扩展。

好消息：95%与运行任何其他服务完全相同。 复用现有模式就好。5%的差异：Agent请求耗时更长（调高负载均衡器的timeout）、响应是流式的（用SSE或WebSocket）、最好的Agent是主动的（定时任务、后台执行）。这些都不新鲜。

核心洞察

作者指出了一个被广泛忽视的问题：当前harness工程的局部最优解——用文件系统做存储再虚拟化、用bash做工具再沙箱隔离——本质上是在用补丁掩盖架构缺陷。正确的做法是从系统视角设计每个层面，让各层相互强化。 比如安全不是prompt的职责，是系统配置；比如memory不是文件系统，是数据库。

Dash（agno-agi/dash）是一个五层架构的参考实现：一个数据查询团队，由Leader、Analyst和Engineer三种Agent组成，通过精心设计的上下文层次（六层：从表结构到运行时上下文）让LLM写出可用的SQL，而不需要靠模型本身变强。它的安全是通过PostgreSQL连接参数和查询级guard强制执行的，不是靠prompt。

当你用系统视角审视软件，正确决策变得显而易见： 你的Agent会获得良好作用域的工具，而不是无限制的bash访问；session、memory和知识存储在数据库里，而不是文件系统里。