Agentic 软件的结构性翻转：从 Harness 工具链的局部优化，到五层 Systems Engineering 的系统级重构
在 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 ID，MCP 调用的 agent 身份也不同。
Interface 工程的核心是让 auth、策略、访问控制在所有表面保持一致。Dash 四个界面共用同一套 agent、工具和知识库，身份映射发生在入口层，后端完全透明。
Infrastructure Engineering 层：95% 是成熟 DevOps，5% 是 agent 特有调整
容器化、云部署、水平扩展这些和普通服务一模一样。唯一需要特殊处理的：agent 请求耗时更长（调高 load balancer timeout）、响应需要 streaming（SSE/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和系统实验。感兴趣可以关注，我们下期见。