想看懂 agent 去哪，先学外壳工程

想知道 agent 往哪走，学一学外壳工程。 先摆一个事实：模型只是 agent 系统的一部分。一旦它开始读文件、调工具、改状态、跨好几步干活，系统好坏越来越取决于它周围那圈软件。 拿编码 agent 走大仓库举例。模型能决定要查文件、搜符号、改一处或跑测试，可这些决定不会自己执行。周围的运行时得管一摊子事：哪些资源可用、请求的操作许不许做、怎么执行、结果留哪条、下一步给模型看什么。 跑得越久越难。历史越滚越厚，全量重放又贵又低效，harness 得决定什么留在上下文里、什么压成摘要稍后取、什么放进上下文之外的持久状态。执行侧同样棘手：长时间任务要扛住中断、别重复干完的活、给要命的操作加权限、还得留够轨迹，好在结果出错时还原现场。 这些都是 harness 的活。它就是围着模型管上下文、工具、执行、状态、检查点、限制和轨迹的那一层。外壳工程干的是设计和改进这一层。看执行轨迹，在有代表性的任务上评 agent，找反复出现的失败模式，再动手改上下文选择、工具接口、状态处理或执行控制。 最后一句是全文的要害。agent 的失败常常改模型治不好，管用的改动在别处：模型看到什么、工具怎么暴露、状态保不保留、某步失败后运行时做什么。 我认同这个判断的分量。前面几篇各说各的：评测要模型和外壳分开算账，Raven 让外壳自己进化，这份长文把外壳工程正式叫成了一个工种。三条线汇到同一处，模型能力照旧要紧，可把它变成可控制、可检查、可测试、可改进的执行过程的，是这一层。 任务越长，这圈软件的担子越重。真要往 agent 方向走，值得先把自己的执行轨迹翻一遍，看看失败到底记在哪一环。