- 确定性在衰减，工程量在外移：模型能力越强，单一 Prompt 红利越薄，真正的价值从「问得好」转移到「把不确定性管回来」
- 4 级核心角色：Prompt（指令）+ Context（材料与记忆）+ Loop（任务编排与自我纠错）+ Harness（权限、沙箱与安全闸门），逐级离模型更远、自主性与风险更高
- 周边配套：Eval（质检）、Tool（工具）、Observability/Trace（全链路可观测）、Cost（成本优化）是生产 Agent 的必选项，不是可选项
- 落地看规模：小项目 Prompt+Context 两人兼任；生产级再补 Loop+Tool；可写真实数据再加 Harness+Trace+Eval；团队规模决定角色是否并岗
2025 年你还在炫耀「我把 Prompt 调得多好」。2026 年，会写提示词已经不算技能了——大模型能力平权之后，优势从「模型内部」转移到了「模型外部」，也就是围绕模型搭起来的那套系统：喂多少材料、怎么编排、怎么兜底、怎么审计。
这篇文章综合一份把 AI Agent 工程拆成四个核心角色的框架（Prompt / Context / Harness / Loop），并接上周边最常被问到的 Eval、Tool、Observability、Cost 四个配套方向，系统讲清楚：它们为什么演化出来、各自解决什么问题、怎么落地、能带来什么价值，以及生产中最常踩的坑和对应解法。文中的角色分层可以直接当团队配置与自检清单用。
一、发展背景：为什么角色在「从内往外」迁移
理解这四个角色，关键是先看一条主线：大模型能力越强，工程重心就越往外移。可以拆成四步演进：
第一步：能力平权，Prompt 红利衰减。早期大家同用差不多的模型，谁能把问题「问得好」谁就有优势，Prompt Engineer 应运而生。但提示词是很薄的技能——模式固定、易被复制，模型一升级，原来费劲调出来的技巧常常失效。当每个人都懂「你是专家、请一步步思考」时，靠提问已经赢不了。
第二步：单轮到多轮，信息喂不进去了。真实任务不是一次问答。一次对话、一次数据处理、一个业务闭环，需要把背景知识、历史记录、检索片段塞进模型，一多就爆上下文窗口。管理「给模型喂什么」变得比「怎么问」更重要——Context Engineer 出现了。
第三步：模型开始「做事」，需要编排循环。模型从「回答问题」进化到「执行任务」——调工具、读文件、写代码、改数据。多步任务怎么拆、怎么决定下一步、失败了怎么重试、什么时候停——这是 Loop Engineer 的领地。
第四步：自主行动带来风险，必须上围栏。一旦 Agent 能真正改数据、发消息、调外部 API，越权和事故就是概率问题。权限、沙箱、审计、操作约束、安全闸门——Harness Engineer 负责把「能自由发挥」变成「在框里自由发挥」。
二、四个核心角色：分工、演进因果与应用场景
Prompt Engineer · 提示词工程师（基础输入层）
角色定位最内层：写指令、定输出规范、配角色与示例。它解决的是「让模型听懂一句话」。典型产出是结构化的 System Prompt、Few-shot 示例、JSON/工具调用输出契约。它不是被淘汰，而是变成了其他三层的地基——所有后续层的最终指令仍由 Prompt 承载。
Context Engineer · 上下文工程师（基础输入层）
角色定位：管理「送入模型的所有信息」。要解决的核心矛盾是信息无限、窗口有限。手段包括 RAG 检索（只取最相关的片段）、记忆分层（会话 / 短期 / 长期 / 向量库）、上下文窗口压缩（丢弃、摘要、替换）。它是知识密集类应用的胜负手。
Loop Engineer · 循环工程师（任务编排层）
角色定位：让 Agent 完成「多步、会失败、需迭代」的自主任务。要解决的核心矛盾是目标明确、路径不确定。手段包括任务拆解与编排（串行 / 流水线 / 并行 / 分层）、多轮迭代（反思 / 评审 / 自我纠错）、自检重试、以及终止条件（轮数上限、预算上限、收敛判定）。它是把模型从「问答工具」变成「执行者」的关键。
Harness Engineer · 围栏工程师（操作约束层）
角色定位：给自主执行划定边界。要解决的核心矛盾是能力更大、越界风险更高。手段包括权限模型（最小权限 / 角色 / 审批）、沙箱与资源隔离、可操作范围白名单、审计日志、以及高风险动作（改数据、发消息、删除）的人工审批闸门。它是生产级 Agent 与 Demo 的分水岭。
应用场景映射：把这四个角色套到真实业务上，答案很清晰——
| 场景 | 业务例子 | 主用角色 | 说明 |
|---|---|---|---|
| 简单问答 | 客服闲聊、通用咨询 | Prompt | 一条好指令 + 输出规范就够 |
| 知识库问答 | 企业文档问答、政策解读 | Prompt + Context | RAG 检索与切片质量决定答案 |
| 多步业务任务 | 工单自动处理、调研报告自动产出 | Prompt + Context + Loop + Tool | 需要编排、调用工具、自我校验 |
| 可改数据的生产 Agent | 自动开票、订单变更、批量更新 | 全 4 角色 + Harness | 必须上权限、审计、审批闸门 |
| 自主长时任务 | 全天候监控、批量内容生产 | 全 4 角色 + Memory | 长期运行最依赖终止条件与护栏 |
三、周边配套：决定能否上生产的四块拼图
四个核心角色解决「怎么造出来」。但一个系统能不能上线、维持、规模化，还要靠四个配套方向。它们在原框架里往往被当成「加分项」，实际上在生产环境是必选项。
LLM Evaluation · 评估工程师（质检层）
核心产出：评测集、评估指标、自动化评测流水线 + LLM-as-Judge 打分器。要回答「这个 Agent 答得好不好」。解决幻觉、错误传播、稳定性回归问题。关键工具是 Golden Set（标注好的标准答案）与 G-Eval / Judge 模型，接入 CI 做回归门禁——每次改 Prompt、换模型、调检索都要过一遍评测，否则你根本不知道改动到底变好还是变坏。
Tool Engineer · 工具工程师（外部能力层）
核心产出：Agent 可调用的工具函数 + 工具 Schema（入参出参契约）+ 异常捕获。工具是 Agent 的「手脚」，MCP（Model Context Protocol）是标准化的「手脚市场」。与 Loop 的边界要分清：Loop 决定「什么时候调」，Tool 保证「工具本身好用」。工具描述不清、返回不可靠，会直接拖垮 Agent 决策。
Observability · 可观测工程师（观测层）
核心产出：全链路追踪 + Token 用量埋点 + 工具调用日志 + 可视化面板。生产排障的起点。要区分两件事：Harness 记的是「安全审计日志」，Trace 记的是「运行细节日志」（排障 + 成本分析）。Langfuse、LangSmith 就是这个方向的主流工具，能直接看到哪一步 token 爆了、哪次调用失败、任务卡在哪个循环。
Cost Engineer · 成本工程师（成本层）
核心产出：Token 成本优化、Prompt 缓存、模型路由、用量配额。常见手法：简单请求走小模型、复杂请求走大模型（模型分级路由）、语义缓存命中重复请求、上下文瘦身减少重复历史、批处理摊薄调用。一个会跳舞的 ReAct 循环能烧掉大把 token，成本控制不是财务问题，是架构问题。
四、怎么落地：按规模分级的团队配置
落地第一问不是「招什么角色」，而是「现在的体量需要哪几层」。原框架给了一条非常实用的分级路线，我们用表格把它固化：
| 项目规模 | 覆盖角色 | 典型形态 | 要不要独立岗位 |
|---|---|---|---|
| 小项目 | Prompt + Context | 简单 RAG 问答 Demo | 一人全包即可 |
| 中型 Agent | Prompt + Context + Loop + Tool | 自动多步任务（只读、不碰真实业务） | 2-3 人分担 |
| 生产级 Agent | 再加 Harness + Trace + Eval | 可修改业务数据、有真实用户 | 至少 1 个专职工程维护护栏与评测 |
| 自研模型场景 | 再增 Model / Embedding / MLOps | 私有化部署、微调自有模型 | 拆成独立小团队 |
一个很真实的行业现状：多数角色在小团队里都是「一人兼任」——一个 Agent 工程师同时兼顾 Prompt + Context + 基础 Loop；只有大厂或复杂企业项目，才把这些拆成独立岗位。所以「角色」更大的意义是责任清单：你可以让一个人干，但不能让任何一块责任没人认领。
落地自检清单（生产上线前逐项打勾）：
- Prompt 是否纳入版本管理（改过回得去，能对比 diff）？
- Context：检索有评测、切片有策略、窗口超限有压缩兜底？
- Loop：有轮数 / 预算上限、失败重试、明确终止条件？
- Harness：写操作有权限审批、全动作有审计日志？
- Eval：有 Golden Set + 自动化评测，接进了 CI 并做了回归门禁？
- Trace：能定位到「哪轮、哪个工具、多少 token」？
- Cost：重复请求有缓存、简单请求路由到小模型？
五、价值：从「能 Demo」到「能交付」
这套角色体系真正的价值，是把 AI 应用从「概率玩具」变成「工程资产」。横向看有五个维度：
| 价值维度 | 由谁提供 | 落地后的可见改变 |
|---|---|---|
| 可靠性 | Loop + Eval | 失败会重试、结果有评测回归，不再「时灵时不灵」 |
| 可控性 | Loop 终止条件 + Harness 闸门 | 该停就停、危险动作有人批准，能解释为什么这么做 |
| 安全性 | Harness + Alignment | 越权被打断、数据不泄漏、全程可审计追责 |
| 成本 | Cost + Trace | token 看得见、省得下，单位任务的边际成本明显下降 |
| 可维护性 | Trace + 版本化 Prompt | 排障有依据、改动可回滚，团队能持续演进而非推倒重来 |
六、落地高频问题与最佳解法
下面 8 个问题是把这套体系落到生产时最高频踩的坑，每个都配了「先讲成因、再给最佳解」的答案。
问题 1：Prompt 不稳定、不可复现
成因：模型是随机的，同一段 Prompt 有时好有时坏；Prompt 散落在代码里，改动无记录，出问题回不去。
最佳解：把 Prompt 当代码管——版本化 + 评测回归。Prompt 抽成独立配置文件纳入 Git；配套一组 Golden Set，任何修改先跑评测，分数不降才允许合并；对稳定性敏感的场景（结构化输出、工具调用）适当降低 temperature，并用 JSON Mode / Function Call 而非「用嘴说格式」。
问题 2：上下文爆炸、超窗口
成因：多轮对话、长文档一次全塞，很快顶穿 Context Window；塞进去还有大量无关信息稀释注意力。
最佳解：Context 的分层策略——先过滤再压缩。第一层用 RAG 只检索相关片段；第二层对越界部分做窗口压缩（重要信息摘要、次要信息丢弃、结构化替换）；日常会话用短期记忆，项目级用向量库长期记忆，按需召回。宁可少喂，不要硬塞。
问题 3：Agent 死循环 / 幻觉放荡 / 失败重试失控
成因：没有终止条件。Agent 会为了一个错误目标反复调自己、反复重试、甚至编造「已成功」，token 烧完、任务还卡着。
最佳解：Loop 工程师的三道硬闸——轮数上限、预算上限、收敛判定。轮数到达即停；每轮累计 token/成本到阈值强制中断；引入校验器（Checker / Evaluator）判断「是否真的完成、是否在重复空转」，进入死循环就切换策略而非继续烧钱。退出后保留现场日志，方便排查。
问题 4：工具调用失败引发连锁失败
成因：工具 Schema 不清晰、返回格式不对、下游 API 抖动，一次失败导致整条 Agent 链崩掉。
最佳解：把工具当一等公民治理——清晰的 Schema + 幂等 + 优雅降级。每个工具的入参出参写成机器可读的 Schema 并写清楚错误语义；工具本身做成幂等，失败可安全重试；单工具失败不炸整条链，提供 fallback 或跳过并记录，让 Loop 决定「换工具还是换策略」。
问题 5：越权操作、数据泄漏
成因：Agent 有了读写能力但没有边界，一条错误指令就能改数据、删记录、发消息。
最佳解：Harness 的最小权限 + 审批闸门。默认 deny，只放开业务必需的权限；高风险动作（写库、删除、外发、转账）全部走人工审批闸门；所有动作写审计日志（谁、何时、调了什么、结果如何），可追踪可追责。越权问题要在系统层拦截，不依赖模型「自觉」。
问题 6：没有评测，改动好坏全靠感觉
成因：改一个 Prompt、换一个模型，是变好还是变坏没人说得清，因为根本没有「答案」和「打分」。
最佳解：建立 Evaluation 流水线——Golden Set + LLM-as-Judge。先标注一批标准问答作为基准；用 G-Eval / Judge 模型对输出自动打分（兼顾正确性、忠实度、格式）；把评测接进 CI，任何改动必须过回归门禁。没有评测门禁的改动，和盲改没区别。
问题 7：黑盒排障，出问题一头雾水
成因：没有链路追踪，只知道「任务失败了」，不知道卡在哪个循环、哪个工具、烧了多少 token。
最佳解：一上来就埋点。每一轮 LLM 调用、每次工具调用、每次重试都打点，带上 Trace ID 串联；用 Langfuse / LangSmith 做可视化，能定位「哪一步 token 爆了 / 哪次调用失败 / 卡在哪个循环」。观测不是上线后再补，是从第一行代码就开始做。
问题 8：成本失控，跑一晚上账单吓死人
成因：自主 Agent、反思循环都是烧钱大户，又缺成本视角的架构设计，账单失控。
最佳解：Cost 的三大杠杆——缓存、路由、瘦身。重复/相似请求用语义缓存命中；按任务难度路由，简单请求走小模型、复杂才走大模型；上下文反复瘦身，历史用摘要替代原文；再叠加预算上限做硬止损。成本问题在架构层治，比在财务层治有效得多。
七、思考：从「看角色」到「看责任」
这套框架最有价值的地方，不是给你一张「岗位表」，而是给你一个责任地图。小团队一个人能跨界，大公司一个人盯一层，但每一层责任都必须有人认领：指令、材料、编排、围栏、质检、工具、观测、成本——缺一不可。
展望下一步：随着 Agent 越来越自主，围栏（Harness）和观测（Trace）会继续向「自治安全」演进——从「人类审批每一个动作」走向「系统自动识别风险 + 分级放权 + 事后审计」；Context 会走向更深的个性化与记忆治理（记什么、忘什么、何时移除）；Eval 会从「题海打分」走向「持续在线评测与在线学习」。角色会变，但「用工程把大模型的能力变成可控交付物」这一主线不会变。
延伸阅读
- 本站前作：AI凭什么自己干活，8大架构一次讲透——单智能体范式 × 多智能体协作拓扑的完整架构地图
- 本站前作：AI Harness：驯服大模型的六柱驾驭体系——Harness 围栏工程的角色定位与落地实操
- 本站前作：OpenAI开源Codex引擎，Agent产品随便造——Harness 的产品化拆解（沙箱 × 审批双闸门）
- 本站前作：主子Agent动态编排怎么实现？5阶段全链路实战——Loop 循环编排的工程落地
- 本站前作：93%的AI项目卡在最后一公里，这样破局——评估门控部署与 Eval 落地的实战视角