AAperture
Back/harness engineering

Agentic Software Is Systems Engineering

Updated 2026-04-15
1 min read
240 words

Agentic Software Is Systems Engineering

Ashpreet Bedi 在 2026-04-14 的文章里给了一个很有价值的纠偏：coding agents 降低了写代码的门槛，但没有降低生产软件的要求。Agent 只是在很多场景下替换了业务逻辑实现方式，并没有替换系统工程本身。

Bell Labs 类比

文章把今天的 agentic software 类比到 1940 年代 Bell Labs 建电话网络时面对的问题：

  • 复杂系统的行为不是单个组件决定的
  • 真正要优化的是组件之间的交互
  • 因此必须有一套专门研究系统边界、约束、可靠性和恢复性的工程方法

今天的 agent 系统也是一样。模型只是系统的一部分，真正决定可用性的，是它与数据、权限、接口和基础设施的连接方式。

五层框架

Ashpreet 把 agentic software 拆成五层：

1. Agent Engineering

  • 模型选择
  • system instructions
  • tool configuration
  • handoff
  • context management
  • observability

目标是：能确定的地方尽量确定，不能确定的地方至少可观察。

2. Data Engineering

memory / context 本质上还是数据问题：

  • schema 怎么建
  • 读写路径怎么定义
  • 用什么数据库或对象存储
  • 怎么保证知识和记忆持续更新

这和 Harness 即记忆 的讨论能接上。

3. Security Engineering

最关键的一句是：

read-only access is not a prompt instruction, it's a tool configuration

权限不应该藏在 prompt 里，而应该落到工具边界与审批层级中：

  • 读操作默认可跑
  • 写操作需要用户批准
  • 敏感操作需要更高层级 sign-off

4. Interface Engineering

同一个 agent 会被多个 surface 访问：

  • REST API
  • Slack
  • MCP server
  • terminal
  • chat UI

每个 surface 的身份模型不同，因此认证与策略不能只在单一入口上成立。

5. Infrastructure Engineering

agent 的可靠性最终会撞到 infra：

  • 环境启动
  • 沙箱隔离
  • 日志与追踪
  • 队列与恢复
  • 长任务持久化

这部分与 Agent Harness 和 轻量 vs 编排 Harness 的边界问题是同一类。

为什么这篇文章重要

它把当前很多“换模型、调 prompt、加 tool”的讨论，重新拉回到更难但也更真实的问题：

  • 权限是不是落在系统边界里
  • context 是不是被当成数据工程对待
  • agent 的行为是不是可观测
  • 多 surface 访问时策略是否一致

这也是为什么 自我验证循环、Claude Code desktop redesign 和这篇文章能拼成一张图：一个在讲产品壳层，一个在讲验证闭环，一个在讲系统分层。

对我们有用的启发

  • 不要把“agent 能跑起来”误判成“系统已经可生产”
  • 权限、审批、隔离要写进系统，不要只写进提示词
  • 如果 context 很重要，就要认真对待 schema、同步和检索路径
  • 任何长跑 agent，最后都绕不开 observability 与 recovery

Counterpoints & Gaps

  • 五层框架很清楚，但没有给出不同团队规模下的最小可行实现
  • 文章强调系统性，但对成本控制与渐进式演进讲得不多
  • 对很多小团队来说，一次性把五层都做“像样”并不现实，实际落地仍需要优先级排序

关联页面

Sources

Linked from