招聘启事上没有，但已经存在的岗位
写着框架工程师的招聘启事还很少见。但只要团队在部署智能体，这份工作就已经存在：有人在打磨工具 schema，有人在定重试上限，有人在维护评分脚本——通常顶着 AI 工程师、平台工程师、后端工程师的头衔。本系列第 1 到第 7 篇论证的正是：这些散落的活儿其实是同一门工程。收官这篇，换成职业能力的视角把这门工程再看一遍。
这个岗位为什么会出现
结构性的原因就是第 1 篇的前提，原封不动。对大多数团队来说模型是固定输入，能动手的是框架的全部。而框架侧的改进空间通常大于提示词文案，于是专门负责这块空间的能力开始有了名字。
Lilian Weng 的框架文章把这场迁移画成一条进化序列：从指令提示词到结构化上下文，到工作流，到框架代码，再到修改框架的优化器代码。每上一级，原本用自然语言指示的东西就多一分变成用代码定义。如果这个方向成立，这个岗位的核心技能会持续从文案功夫移向系统设计。
需要的能力并不新
好消息是：所需能力大部分是既有软件工程的重新排布。接口设计的感觉移到工具表面设计；失败处理的设计移到失败返回格式；版本管理与可观测的习惯移到框架指纹；最小权限原则移到评估完整性装置。在这之上再加两样。一是评估素养：会写评分细则、会测评审与人工判定的一致率、能读出指标的盲区。二是精确的文字。在一行工具描述就能改变行为的世界里，写出简短而无歧义句子的能力不是装饰，而是接口质量。
六块肌肉：按层级的练习地图
本博客的框架工程 RPG 把 27 个场景分成六层。把每一层练的肌肉与本系列的文章配对，就是一张练习地图。
| 层级 | 练的肌肉 | 搭配阅读 |
|---|---|---|
| 1. 观测与指纹 | 记录并复现变更的习惯 | 第 1 篇、第 7 篇 |
| 2. 划边界 | 判断事件的主人是模型还是框架 | 第 1 篇 |
| 3. 循环设计 | 重试上限、停止条件、升级路径 | 第 4 篇 |
| 4. 上下文预算 | 拿出来重于放进去；playbook 与丢弃策略 | 第 2 篇、第 3 篇 |
| 5. 评估者瓶颈 | 意识到评分的上限，并沿阶梯往上爬 | 第 5 篇 |
| 6. 自我改进循环 | 察觉指标与任务分岔、识破奖励作弊的眼睛 | 第 6 篇 |
顺序是有意的。没有观测就去动循环，说不出什么变好了；没有评估者就转自我改进，采纳的只会是噪声。游戏里的层级锁，就是强制这个顺序的装置。
把练习搬进运维
游戏里练出的手感，要移植到一个真实系统上才算完成。推荐的路径是从小处开始。照 Anthropic 的智能体构建指南的建议，从最简单的配置出发，挑一个你正在运营的自动化，走四步：给框架划边界、写出组件清单；用清单做出指纹、盖在评估结果上；把评分标准写成评分细则；再挂一个牵制指标当警报。这四步分别是本系列第 1、7、5、6 篇的摘要，而且大小刚好，任何团队一周之内都能启动。
人的角色不会缩小
关于这个岗位的前景，补一句。即使自己修改自己框架的自我改进循环成为标配，人的角色也是在移动，而不是在消失。Weng 的文章在难题清单的末尾也写道：人的监督应该增加而不是淡出。决定测什么、判读牵制指标的警报、抽查被采纳的变更——这些必须留在循环之外，而那正是框架工程师的位置。循环越快，这个位置越重。
亲手练习
如果今天就开始，顺序是这样：从框架工程 RPG 的第 1 层起逐层往上爬，读每一次复盘；在哪一层卡住了，就回到上表里配对的文章。觉得提示词侧的基本功偏弱，就同步用提示词工程练习工具。
- 上一篇：框架指纹与版本管理 — 让没有记录的变更可以追踪
- 从系列开头读起：什么是框架工程
参考资料
- Harness engineering for self-improvement — Lilian Weng, 2026-07-04 —— 从指令提示词到优化器代码的进化序列、人的监督应当增加的判断，都在这篇文章里。
- Building effective agents — Anthropic, 2024-12-19 —— 从最简单的配置开始的建议在这篇文章里。
- 开头对岗位的描写是一般化叙述，不指向任何具体公司；练习路径是本博客构造的提议。
현재 단락 (1/22)
写着框架工程师的招聘启事还很少见。但只要团队在部署智能体，这份工作就已经存在：有人在打磨工具 schema，有人在定重试上限，有人在维护评分脚本——通常顶着 AI 工程师、平台工程师、后端工程师的头衔...