跳转至

Agent 时代，我们架构师应该学什么？

Ch04.400 Agent 时代，我们架构师应该学什么？

📊 Level ⭐⭐ | 6.1KB | entities/agent-时代我们架构师应该学什么.md

Agent 时代，我们架构师应该学什么？

架构师（JiaGouX） 我们都是架构师！

→ 原文存档

深度分析

1. 筛选能力比学习路线图更耐用

在 Agent 领域，"filter > feed"——评估新技术的半衰期比追路线图更重要。模型封装层、CLI 参数、某个"类 Devin 产品"的半衰期通常很短；协议、状态、沙箱、评估、工具契约这些东西，半衰期会长很多。前者更多是工具选择，后者会慢慢变成系统能力。能在最热的时候说"我半年后再看"，是架构师难得的克制。

2. 上下文是运行时工作集，而非聊天记录

Agent 跑长任务时，很多失败表面看是"模型没想明白"，往里看常常是上下文坏了——目标被工具输出淹没、旧错误一直留在窗口里、压缩把用户最初的约束磨平。把上下文按运行时工作集分层设计（模型窗口 / 会话状态 / 文件数据库 / 项目规范 / 工具层），比当聊天记录或资料仓库更顺。Claude Code 92% 缓存命中率的背后，正是把稳定内容和动态内容分得很干净。

3. 工具设计即业务接口设计

模型不是人类工程师——人看到 400 Bad Request 会自己翻文档，模型靠的是工具的名字、描述、参数、返回和错误消息来理解外部世界。五到十个命名清楚、边界清楚的工具，通常比二十个互相重叠的工具更稳。工具描述本身就是一份很小的接口文档：写宽了模型会滥用，写窄了模型不敢用，返回太多窗口会变脏，错误太抽象模型会重复犯错。

4. 评估前置是工程能力的分水岭

Agent 系统最麻烦的地方在于，它很多时候不会显式崩掉，而是给一个看上去挺像答案的答案。把 eval 类比成 Agent 的单元测试——它不保证系统永远正确，但至少能让团队知道这次改动有没有把昨天还正常的能力搞坏。没有这层东西，团队很容易陷在体感讨论里。Cursor 复盘 Harness 也印证了这点：模型决定能力上限，Harness 决定生产下限，但评估才是让下限可度量的手段。

5. Harness 是模型的运行底座，而非薄壳

Harness 在长任务里会撞上后端同样的问题：状态、队列、日志、权限、恢复、审计、成本。模型负责选下一步，Harness 负责验证、执行、捕获输出、决定反馈、设置检查点、必要时调度子任务。同一个模型，放在不同的上下文策略、工具契约、评估体系和权限边界里，表现差得很远。Agent 产品的质量很难只按模型版本讨论，更准确的发布单元是模型加 Harness 的组合。

实践启示

  1. 用筛选问题评估新框架：问自己——半年后它还重要吗？能接进现有系统吗？解决什么真实失败模式？能被 trace 和 eval 证明有用吗？多数新框架晚点看没关系，稳定原语错过了才麻烦。

  2. 把上下文分层当作架构决策：当前目标、关键约束、最近观察放模型窗口；任务计划、已完成动作、待办放会话状态；大对象、日志、代码、历史文档放文件/数据库；AGENTS.md、README、Runbook、团队约定放项目规范层。

  3. 用接口文档思维写工具描述：一个工具要让模型看懂——什么时候该用、什么时候不该用、参数填什么、返回哪些是关键结果、失败以后下一步怎么修、危险动作有没有权限和确认。

  4. 上线前先做一版哪怕粗糙的评估集：从真实 trace 里长出来，第一次上线前哪怕只有五十条样本也比没有强；每次失败就把样本补进去，每次改 prompt、换模型、调上下文压缩都跑一遍。

  5. 从窄目标小闭环起步：一个明确目标 + 单 Agent 主循环 + 三到七个边界清楚的工具 + 窗口外状态层 + 沙箱 + trace + 五十条初始评估样本 + 能回滚的发布方式。多 Agent 和长期记忆可以晚一点——Agent 早期最值钱的地方，不在它会做多少事，而在团队能不能看清它怎么失败。

→ 原文存档

关联阅读