Agentic Software Is Systems Engineering
What it is
Agentic software 把部分业务逻辑交给模型和 agent loop，但它没有让软件工程消失。相反，生产可用的 agent 系统更像系统工程：模型只是组件之一，真正决定可靠性的是数据、权限、接口、运行环境、观测和恢复机制如何协同。
Ashpreet Bedi 的核心论点是：coding agents 降低了写代码的门槛，但没有降低生产软件的要求。
Why it matters
这条判断可以纠正“换模型、调 prompt、加工具”式的浅层优化。Agent 系统失败时，问题常常不在模型单步能力，而在系统边界没有被工程化：权限藏在 prompt 里，记忆没有 schema，工具输出不可观测，长任务无法恢复，多 surface 入口的身份策略不一致。
对 Jean 的 wiki 和 OpenClaw 工作流来说，这意味着 agent harness 的重点不是做一个大框架，而是把文件、skills、logs、wiki、approval、review 和 automation 组成可维护系统。
Evidence across sources
- Ashpreet Bedi 将 agentic software 拆成五层：Agent Engineering、Data Engineering、Security Engineering、Interface Engineering、Infrastructure Engineering。
- Dash 数据 agent 案例显示，同一 agent 逻辑可以暴露为 REST、Slack、web UI、CLI；权限、数据和工具配置必须跨 surface 一致。
- 多个 vault 页面连接到同一判断：Agent Harness、Lightweight vs Orchestration Harness、9-Layer Production AI Architecture。
Five Layers
| Layer | Core question | Common failure |
|---|---|---|
| Agent Engineering | 模型、指令、工具、handoff、context 如何组合？ | 只调 prompt，不设计循环和观测 |
| Data Engineering | context、memory、knowledge 如何读写和更新？ | 把记忆当聊天历史，不当数据系统 |
| Security Engineering | 权限、审批、隔离、审计在哪里执行？ | 用 prompt 伪装权限边界 |
| Interface Engineering | REST、Slack、MCP、terminal、chat UI 如何共享策略？ | 每个入口有不同身份和权限语义 |
| Infrastructure Engineering | 长请求、流式、后台任务、恢复如何运行？ | 把 agent 当普通 request/response 服务 |
Open questions
- 小团队的最小可行 systems engineering 是什么，哪些层可以先用文件和约定替代平台？
- 成本工程是否应该成为第六层，因为 token、推理、缓存和重试已经是系统约束？
- 对非数据密集型 agent，Dash 案例中的数据库化 memory 和 RBAC 是否仍是默认方向？