在 Agent 爆炸式增长的 2026 年最常见的画面是开发者兴奋地堆砌各种 harness、MCP、工具调用和 filesystem 记忆以为“LLM Tools 产品”。我起初也以为 agentic 软件的核心就是把模型能力快速外化成工具链直到完整刷完 Ashpreet Bedi 这篇深度拆解才猛然意识到这不是工具升级而是整个行业正在重蹈 Bell Labs 1940 年代的覆辙。当时他们构建全球最复杂的电话网络时发现单个组件再优化也无法保证整体系统的可靠性和容量——真正决定成败的是组件之间的交互方式。他们因此发明了 Systems Engineering。今天agentic 软件生态正重复同样的错误用 filesystem 做记忆、用 bash 做万能工具再用虚拟层去打补丁。这些“局部最优”正在制造系统级债务而真正的高手早已把 agent 当成普通软件用五层 Systems Engineering 去设计交互、约束和演化。当 LLM 把写代码的边际成本压到接近零稀缺的就变成了把这些代码组织成一个稳定、可观测、可扩展的系统的能力。Agent 不是魔法它只是把业务逻辑从手写代码换成了模型推理但生产级要求——安全性、多租户、上下文一致性、可观测性——一分没少。Systems Engineering 不是新概念它是 80 年老课在 AI 时代的重现。Agent Engineering 层行为确定性与可观测性才是起点你的 agent 或 multi-agent 团队不是随意堆 prompt而是需要明确定义执行流、工具配置、handoff 机制和上下文管理。模型指令在运行时动态组装行为尽量确定deterministic不确定部分必须完全可观测。这层不是“让模型聪明”而是“让模型的行为可预测、可调试、可迭代”。Dash 里 Leader agent 把请求路由给 Analyst只读和 Engineer可写两个 specialist 用同一套工具接口却通过配置而非 prompt 实现完全不同的权限——这就是 agent 工程的系统思维。Data Engineering 层上下文就是数据记忆必须用数据库思维Agent 再强也只是上下文的函数。记忆、知识、会话都必须用成熟的数据工程模式结构化 schema、PostgreSQL 做快速读写、对象存储做长期归档、管道保持知识实时更新。Dash 构建了六层 grounded context表元数据、人为标注、已验证查询模式、机构知识、错误学习记录、实时 schema 探测。这些数据不是扔进 filesystem而是 curated 进 PostgreSQL同时运行自我学习循环——agent 遇到 type error 后自动诊断、保存修复下次同样场景直接命中。查询第 100 次远胜第 1 次不是因为模型变强而是数据层在持续进化。Security Engineering 层安全是系统属性不是 prompt 指令“只读权限”不是写在 system prompt 里的愿望而是工具配置里的 JWT-backed 权限。读操作自由执行写操作需要用户批准敏感操作需要 admin 签批所有动作必须日志化、可审计、可查询。更重要的是隔离一个用户的上下文绝不能泄露到另一个。Dash 在生产环境用 RBAC JWT每条查询强制 scope 到 user_id通过 eval suite 直接测试越权、泄密、破坏性 SQL——数据库本身拒绝非法操作而不是靠模型“听话”。Interface Engineering 层多表面身份系统必须一致今天一个 agent 可能同时暴露在 REST API、Slack bot、Web UI、CLI、MCP server 等多个表面。Slack 的 thread ID 不是你的产品 user IDMCP 调用的 agent 身份也不同。Interface 工程的核心是让 auth、策略、访问控制在所有表面保持一致。Dash 四个界面共用同一套 agent、工具和知识库身份映射发生在入口层后端完全透明。Infrastructure Engineering 层95% 是成熟 DevOps5% 是 agent 特有调整容器化、云部署、水平扩展这些和普通服务一模一样。唯一需要特殊处理的agent 请求耗时更长调高 load balancer timeout、响应需要 streamingSSE/WebSocket、最佳 agent 是主动式的支持 scheduled tasks 和 background execution。Dash 用极简 Python 容器 Docker Compose本地一键启动部署到任意云——标准 ASGI server 处理 streaming剩下的全是复用现有基础设施。为了把当前主流做法和 Systems Engineering 的差异说清楚我把两种路径做了一个决策矩阵基于真实 agentic 生产项目的长期观察维度Harness-first当前主流Systems-first五层工程长期系统影响组件优化单个工具/记忆/权限局部打补丁五层交互先行设计避免级联债务维护成本指数级降低安全性依赖 prompt “请不要泄密”RBAC JWT 数据库级强制 eval suite生产就绪合规无死角上下文演化每次请求重构 filesystem 记忆结构化数据层 自我学习循环智能随使用次数自然提升多界面一致性每个表面单独处理身份和策略统一后端 入口层映射跨表面零裂隙可扩展性强开发者心智负担持续修复“这个 hack 又出问题了”专注业务 复用 80 年成熟模式从救火转为系统设计师这个矩阵不是理论而是 Ashpreet Bedi 用 Dash 这个真实开源项目https://github.com/agno-agi/dash验证过的路径。你可以直接 clone、一键 docker compose up就拥有一个完整五层落地的 self-learning data agent。为什么 2026 年的 agentic 软件Systems Engineering 成了真正的分水岭当前 harness 工程把精力全放在“怎么让模型更听话”上却忽略了生产软件的本质要求。Ashpreet 反复强调agentic 软件就是普通软件只是业务逻辑换成了 agent接口从 request/response 变成了多表面 streaming。单个组件再优化也无法解决系统层面的涌现行为。当你从系统视角出发MCP vs CLI 之类的争论自然消失你会自然选择 scoped tools 而非 unfettered bash选择数据库而非 filesystem。作为 Builder 或 AI 系统决策者你现在最该问自己的问题是你当前 agent 项目里哪个层最弱是数据层还在吃 filesystem 老本还是安全层还靠 prompt 祈祷欢迎在评论区分享你正在构建的 agent 里最让你头疼的那个系统级痛点或者你打算第一个强化的五层中的哪一层。我们一起把“能跑”的 agent 变成“能长期 hold 住”的生产级系统。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。