从 Prompt 到 Harness，为什么 Agent 工程的重点变了

摘要

过去一年期间，agent工程主线已经从prompt转向harness架构设计，未来的主线应该也会是agent的系统架构升级而不单单是大模型的能力和提示词。

如果你真的做过一个能跑在真实环境里的 Agent，就会很快发现，Prompt 只是入口，不是全部。

Agent 真正困难的地方，不是让模型在某一轮回答里表现得聪明，而是让它在多轮任务中持续获取上下文、正确调用工具、保存中间状态、从失败中恢复、留下可审计的轨迹，并最终稳定地产生可验证的结果。所以Agent 工程的重心正在从 Prompt Engineering 转向 Harness Engineering。

Prompt 决定模型这一轮怎么理解任务。

Harness 决定模型在什么样的工程系统里持续工作。

这篇文章想聊的就是这个变化。

目录

• Prompt 时代解决的是什么问题
• 为什么 Agent 出现后 Prompt 不再足够
• Context Engineering，管理模型这一轮应该看到什么
• Tooling，工具不是 API 列表，而是 Agent 的行动空间
• Harness Engineering，Agent 真正开始工程化的地方
• Eval，为什么不能只看一次 Demo
• Protocol 和 Runtime，Agent 走向生产环境后的必然问题
• 一个最小 Agent Harness 应该长什么样
• 开发者应该怎么落地
• 总结

1. Prompt 时代解决的是什么问题

Prompt Engineering 没有过时，它依然重要，而且在很多场景里仍然是性价比最高的优化手段。

在大模型应用早期，大部分任务本质上是单轮或者短链路任务，比如：

场景	典型任务
文本分类	判断情绪、意图、标签
信息提取	从文本里抽取字段
文本改写	润色、翻译、风格转换
摘要生成	长文摘要、会议纪要
问答	基于上下文回答问题
结构化输出	输出 JSON、表格、代码片段
简单函数调用	根据用户意图调用一个工具

这些任务的共同点是，模型通常只需要在一次输入里完成判断。所以那个阶段，核心问题确实是：

• system prompt 怎么写；
• 用户指令怎么组织；
• few-shot 示例怎么给；
• 输出格式怎么约束；
• 怎么减少幻觉；
• 怎么提高 instruction following；
• function calling 的 schema 怎么设计。

这时候 Prompt 是非常关键的，因为系统本身还比较简单。你把需求说清楚，给几个例子，要求输出 JSON，再加一点边界条件，很多任务就能跑起来。

比如一个最简单的信息抽取任务：

你是一个信息抽取助手。 请从用户输入中提取姓名、手机号、城市，输出 JSON。 如果字段不存在，返回 null。

这种场景里，Prompt 的收益很直接，写得越清楚，模型越稳定。但是问题在于，Agent 不是这种东西。

Agent 不是「回答一次」。

Agent 是「行动一段时间」。

这两个东西的工程复杂度完全不一样。

2. 为什么 Agent 出现后 Prompt 不再足够

Agent 是一个能在循环中使用工具、观察结果、更新状态，并继续行动的系统。这句话很简单，但它会立刻带来一堆 Prompt 解决不了的问题。

假设你要做一个「自动修复 GitHub Issue 的 coding agent」，最早你可能会写一个 Prompt：

你是一个资深软件工程师。 请阅读这个 Issue，分析原因，修改代码，并确保测试通过。

这看起来没问题。但模型真的开始干活后，你会马上遇到这些问题：

• 它该先看哪些文件？
• 它怎么知道项目怎么启动？
• 它怎么知道测试命令是什么？
• 它改了一半失败了怎么办？
• 它怎么判断自己不是「看起来修好了」，而是真的修好了？
• 它能不能执行 shell？
• 它的每一步操作要不要审计？
• 上下文快满了，哪些信息要保留，哪些可以丢掉？

这些问题不是「Prompt 再写清楚一点」就能彻底解决的，它们属于系统设计问题。也就是说，当任务从「生成答案」变成「持续行动」，工程重心就会自然上移。

从写 Prompt，变成设计 Agent 的运行环境。这就是从 Prompt 到 Harness 的核心变化。

3. 一张表看懂 Agent 工程的层级变化

如果把一个现代 Agent 系统拆开，大概可以分成这几层：

层级	关心的问题	典型产物
Prompt	模型这一轮怎么理解任务	system prompt、developer instruction、few-shot、输出格式
Context	模型这一轮应该看到什么	RAG、记忆、状态摘要、任务笔记、上下文裁剪
Tooling	模型能采取什么行动	function calling、MCP server、工具 schema、权限设计
Harness	模型在什么循环里工作	agent loop、checkpoint、retry、日志、审批、恢复机制
Eval	怎么判断它真的变好了	任务集、grader、trace、回归测试、人工抽检
Protocol	Agent 和工具、Agent 和 Agent 如何互通	MCP、A2A、项目约定文件、技能包
Runtime	它在哪里安全运行	sandbox、权限模型、资源隔离、审计、限流

过去大家最关注第一层，现在真正复杂的 Agent 项目，难点经常在后面几层。

这也是为什么 OpenAI、Anthropic、Google 这些公司最近的工程材料，不再只讲「怎么写 Prompt」，而是在持续讲：

• context engineering；
• tool design；
• agent harness；
• evals；
• multi-agent workflow；
• MCP；
• sandbox；
• permission model；
• runtime environment。

这是应用形态变化之后，工程问题自然长出来了。

4. Context Engineering：管理模型这一轮应该看到什么

Prompt Engineering 关心的是「指令怎么写] ，Context Engineering 关心的是「这一轮模型应该看到什么」。

这两个问题很像，但不是一回事。在传统 Prompt 场景中，上下文通常是静态的。你把 system prompt、用户输入、参考资料塞进去，模型回答一次，任务结束。

但 Agent 不一样，它会不断产生新状态：

• 工具调用结果；
• 搜索结果；
• 中间计划；
• 待办列表；
• 错误日志；
• 上一轮失败的原因；
• 已经生成的中间产物。

这些东西不可能全部无脑塞进上下文。

很多开发者有一个误区，觉得只要模型上下文越来越长，就可以把所有东西都丢进去。但实际做 Agent 时会发现：上下文越长，噪声越多，模型越容易分心，越容易被无关信息带偏，也越容易在关键细节上失焦。

Anthropic 在 2025 年的 context engineering 文章里有一个很重要的判断，context 应该被当作一种有限资源来管理，而不是越多越好。它强调的不是「把更多 token 塞进去」，而是「持续维护最有价值的一组 token」。

对于 Agent 来说，context engineering 不是一次性构造 Prompt，而是每一轮都要做选择：

• 哪些信息应该直接进入上下文；
• 哪些信息应该压缩成摘要；
• 哪些信息应该写入外部记忆；
• 哪些信息应该等模型需要时再通过工具读取；
• 哪些历史工具结果已经没有必要保留；

举个例子：如果一个 coding agent 要修一个 bug，它不应该一开始就把整个代码仓库塞给模型。

更合理的方式是：

• 先给它任务描述；
• 给它项目结构；
• 给它关键约定，比如测试命令、代码风格；
• 允许它用 rg、find、read_file 等工具按需探索；
• 对读过的关键文件保留摘要；
• 对冗长的日志只保留错误片段；
• 对已经验证过的结论写进任务笔记；
• 上下文快满时做 compaction，只保留关键状态。

这就是 context engineering。不是「更长的 Prompt」，而是「动态工作内存管理」。

5. Tooling，工具不是 API 列表，而是 Agent 的行动空间

很多人做 Agent 的第二个误区，是把工具设计理解成「给模型挂几个 API」。

比如：

[ 	"search",	"read_file", 	"write_file", 	"run_command", 	"send_email", 	"query_database"  ]

但真实情况是，工具越多，Agent 不一定越强。如果工具设计不好，Agent 反而更容易失控。因为工具是模型的行动空间，工具的名字、描述、参数、返回值、权限边界，都会影响模型行为。

• 工具如果描述太模糊，模型就不知道什么时候该用；
• 两个工具功能重叠，模型就会反复犹豫，甚至选错；
• 工具返回值太长，会污染上下文。
• 工具权限太大，会带来安全风险。
• 工具失败信息不清楚，模型就不知道怎么恢复。

举个例子：你给 coding agent 一个工具

{
	"name": "run_command",
	"description": "Run a shell command"
}

这当然很强，但也很危险。因为它可以跑测试，也可以删文件；它可以查看环境，也可以执行高风险操作。如果没有权限模型、审批机制、命令白名单、工作目录限制、日志记录，这个工具就不是能力，是风险。

更好的设计应该考虑：

设计点	问题
工具职责	这个工具到底解决什么问题
参数 schema	参数是否清晰、可校验
返回格式	是否短、准、结构化
错误信息	失败后模型能不能知道下一步怎么办
权限边界	是否需要用户批准
可观测性	工具调用是否可记录、可回放
可组合性	能否和其他工具形成稳定 workflow

所以，一个成熟 Agent 的工具层，往往不是「API 越多越好」，而是「最小可用工具集 + 清晰语义 + 可控权限 + 高信噪比返回」。

这也是 MCP 这类协议变得重要的原因。MCP 的定位不是让模型多几个函数，而是让 AI 应用用一种标准方式连接外部数据源、工具和工作流。官方文档里把 MCP 类比成 AI 应用的 USB-C 接口，这个比喻很形象，它解决的是连接标准化问题。

当 Agent 真的要连接文件系统、数据库、设计工具、搜索引擎、企业内部系统时，工具层就不再是几个 function call，而是一个生态接口问题。

6. Harness Engineering，Agent 真正开始工程化的地方

什么是 Harness？在软件测试里，test harness 通常指测试脚手架。但在 Agent 语境里，harness 可以理解成更广义的 agent scaffold / runtime shell，也就是包在模型外面的那套工程系统。它负责让模型不是孤零零地回答一句话，而是在一个受控环境里持续行动。

一个 Agent Harness 通常包括：

• 任务初始化；
• 上下文构造；
• 工具注册；
• 权限控制；
• agent loop；
• 状态管理；
• 中间产物管理；
• checkpoint；
• 失败重试；
• 日志和 trace；
• 自检和验证；
• 人工审批；
• 终止条件；
• 环境清理。

如果说 Prompt 是方向盘，那么 Harness 就是车身、刹车、仪表盘、安全带和维修记录。没有 Harness，模型也许能跑起来，但你很难让它稳定、可控、可复现、可调试。

Anthropic 在「Effective harnesses for long-running agents」里讲了一个很典型的长任务问题。一个 Agent 如果要跨多个上下文窗口持续做事，就不能每次都从零开始，也不能每次都靠模型自己猜项目当前状态。

他们提到的做法包括：

• 第一个 initializer agent 负责初始化环境；
• 创建 init.sh，让后续 Agent 知道怎么启动项目；
• 创建 progress 文件，记录之前做过什么；
• 创建 feature list，把大任务拆成可验证的小功能；
• 每次只推进一个小目标；
• 每次结束前提交进度、记录状态；
• 下一次开始时先读 progress、git log 和任务列表；
• 在继续开发前先跑基础验证，确认环境没有坏。

这个工作结构让一个不完美的模型，也能在相对稳定的轨道上持续推进，这就是 Harness Engineering 的意义，它通过设计一个环境，让模型即使会犯错，也能被约束、被观察、被纠正、被恢复。

7. Prompt、Context、Harness 的区别

可以用一个 coding agent 的例子来区分。

假设任务是：

修复登录接口中空密码也能通过认证的问题。

Prompt 层关心什么

Prompt 层会写：

你是一个资深后端工程师。 请修复认证绕过漏洞。 修改代码前先分析原因。 修改后运行测试。 不要改动无关文件。

它关心的是模型这一轮应该怎么理解任务。

Context 层关心什么

Context 层会决定：

• 要不要把 README.md 放进上下文；
• 要不要把 auth.py 放进上下文；
• 要不要把测试失败日志放进上下文；
• 要不要把数据库 schema 放进上下文；
• 上一轮模型读过的无关日志要不要清掉；
• 当前上下文快满时，哪些信息要摘要保留；
• 哪些文件路径只保留引用，等模型需要再读。

它关心的是模型这一轮应该看到什么。

Tooling 层关心什么

Tooling 层会设计：

• read_file；
• edit_file；
• run_tests；
• search_code；
• inspect_logs；
• git_diff；
• request_approval。

它关心的是模型能做什么，以及每个动作的边界在哪里。

Harness 层关心什么

Harness 层会安排整个循环：

1. 初始化任务；
2. 读取项目约定；
3. 搜索相关文件；
4. 制定计划；
5. 修改代码；
6. 运行测试；
7. 如果失败，读取错误并修复；
8. 生成 diff；
9. 做安全检查；
10. 写入 progress；
11. 输出最终报告。

它关心的是模型如何在一个可控流程里完成任务。

Eval 层关心什么

Eval 层会检查：

• 漏洞是否真的修复；
• 原有登录流程是否被破坏；
• 是否新增测试；
• 是否修改了无关文件；
• 是否引入新的安全风险；
• 多次运行是否稳定；
• 换一个模型后是否退化。

它关心的是整个系统是不是真的变好了。

8. Eval，为什么不能只看一次 Demo

Agent 最容易骗人的地方，是 Demo。一个 Agent 在演示里成功一次，不代表它能在真实场景里稳定工作。尤其是多轮 Agent，它的失败往往不是一开始就失败，而是一步一步偏掉。

• 它可能第一步读对了文件。
• 第二步理解错了日志。
• 第三步改了一个看起来合理但其实不完整的补丁。
• 第四步测试没跑全。
• 第五步自信地告诉你任务完成。

这就是为什么 Eval 对 Agent 特别重要，传统 LLM eval 可以只看输入和输出，但 Agent eval 不能只看最终回答。

还要看：

• 它调用了哪些工具；
• 工具参数是否正确；
• 中间步骤是否合理；
• 有没有重复尝试同一条死路；
• 有没有越权；
• 有没有修改环境；
• 最终环境状态是否真的满足要求；
• 成本和耗时是否可接受；
• 多次运行是否稳定。

Anthropic 在「Demystifying evals for AI agents」里把几个概念区分得很清楚：

概念	含义
task	一个有输入和成功标准的测试任务
trial	对某个任务的一次尝试
grader	评分逻辑，可以是代码、模型或人工
transcript / trace	一次尝试的完整过程记录
outcome	任务结束后的真实环境状态
evaluation harness	运行评估任务、记录过程、评分并聚合结果的基础设施
agent harness	让模型像 Agent 一样行动的系统

评估一个 Agent 时，评估的不是裸模型，而是模型和 harness 共同工作的结果，这点非常关键。因为同一个模型，放在不同 harness 里，表现可能完全不同。

一个没有工具约束、没有状态管理、没有测试反馈的 Agent，可能看起来很聪明，但稳定性很差；另一个模型能力略弱，但有好的工具、好的上下文管理、好的 checkpoint、好的 eval，反而可能在生产环境里更可靠。

9. Protocol 和 Runtime：Agent 走向生产后的必然问题

当 Agent 只是一个 Demo 时，你可以把所有东西写死在代码里。

• 工具写死
• Prompt 写死
• 上下文写死
• 权限也先不管

但只要你想把 Agent 放到真实产品或团队流程里，协议和运行时问题就会马上出现。

9.1 MCP 解决的是工具和上下文连接问题

MCP 让 AI 应用用标准方式连接外部系统，比如本地文件、数据库、搜索、业务系统、设计工具等。它的意义不是「又多了一个协议」，而是让工具接入从私有胶水代码变成可复用接口。

对于开发者来说，这有两个好处：

• 你可以把内部系统封装成 MCP server，让不同 Agent 复用；
• 你可以让 Agent 用更统一的方式发现工具、调用工具、获取上下文。

这会让 Agent 工程从「每个项目手写一套工具适配」慢慢走向「工具生态」。

9.2 A2A 解决的是 Agent 之间的协作问题

MCP 更偏 Agent 到工具，A2A 更偏 Agent 到 Agent。

Google 推出的 Agent2Agent 协议，目标是让不同框架、不同厂商、不同系统里的 Agent 能够发现彼此、交换信息、协同完成任务。

因为复杂任务很难永远靠一个 Agent 完成。未来更常见的结构可能是：

• 一个主 Agent 负责理解用户目标；
• 一个检索 Agent 负责找资料；
• 一个代码 Agent 负责实现；
• 一个测试 Agent 负责验证；
• 一个安全 Agent 负责审查；
• 一个总结 Agent 负责交付结果。

这些 Agent 怎么互相发现、怎么传递任务、怎么报告状态、怎么返回 artifact，就会变成协议问题。

9.3 Runtime 解决的是安全运行问题

只要 Agent 能操作真实系统，Runtime 就绕不开。尤其是这些能力一旦打开：

• 读写文件；
• 执行 shell；
• 调用企业内部 API；
• 发邮件；
• 写数据库；
• 浏览网页；
• 操作浏览器；
• 修改代码仓库；
• 创建工单；
• 发起支付或审批。

这时候必须考虑：

运行时能力	风险
sandbox	防止 Agent 影响宿主环境
permission model	控制哪些动作需要审批
audit log	记录 Agent 做过什么
secret management	防止泄露密钥和凭证
network policy	控制访问哪些外部地址
filesystem boundary	限制读写范围
rate limit	防止失控调用
rollback	出错后能恢复
human-in-the-loop	高风险动作必须有人确认

这也是为什么 coding agent 是最好的 Agent 工程试验场，因为 coding agent 几乎同时包含了所有关键问题：

• 它需要读大量上下文；
• 它需要调用工具；
• 它需要执行命令；
• 它需要修改环境；
• 它需要验证结果；
• 它需要处理失败；
• 它需要留下 diff；
• 它需要可回滚；
• 它需要权限边界。

把 coding agent 做明白，很多 Agent 工程问题就都碰过一遍了。

10. 一个最小 Agent Harness 应该长什么样

下面给一个非常简化的伪代码，它不是完整框架，只是帮助理解 Harness 的结构。

class AgentHarness:
    def __init__(self, model, tools, policy, evaluator, memory):
        self.model = model
        self.tools = tools
        self.policy = policy
        self.evaluator = evaluator
        self.memory = memory
        self.state = {}

    def run(self, task):
        self.initialize_task(task)

        while not self.should_stop():
            context = self.build_context(task)

            action = self.model.decide(
                context=context,
                tools=self.tools.schemas()
            )

            if not self.policy.allow(action):
                approval = self.request_human_approval(action)
                if not approval:
                    self.record("action_rejected", action)
                    break

            result = self.execute_action(action)

            self.update_state(action, result)
            self.record_trace(action, result)

            if self.need_checkpoint():
                self.save_checkpoint()

            if self.need_compaction():
                self.compact_context()

            if self.need_eval():
                verdict = self.evaluator.check(
                    task=task,
                    state=self.state,
                    trace=self.get_trace()
                )

                if not verdict.ok:
                    self.repair(verdict)

        return self.finalize()

一个真实的 Harness 会复杂得多，但核心就是这些：

模块	作用
build_context	决定这一轮给模型什么信息
model.decide	让模型基于上下文和工具做决策
policy.allow	判断动作是否允许执行
execute_action	调用真实工具
update_state	更新任务状态
record_trace	记录过程，方便审计和调试
save_checkpoint	保存恢复点
compact_context	压缩上下文，避免污染和溢出
evaluator.check	验证结果是否达标
repair	失败后进入修复流程

你会发现，这里 Prompt 只是其中一部分，真正的 Agent 工程，是围绕模型搭一个能工作、能反馈、能恢复、能验证的闭环。

11. 开发者落地时，可以按这 7 个问题自查

如果你正在做 Agent，不管是客服 Agent、数据分析 Agent、coding Agent，还是企业内部自动化 Agent，都可以用下面这几个问题检查工程成熟度。

11.1 你的 Agent 有没有明确的任务状态

不要只靠对话历史保存状态。至少要有结构化状态，例如：

{
  "task_id": "fix-auth-bypass",
  "goal": "修复空密码认证绕过问题",
  "status": "in_progress",
  "completed_steps": [
    "定位认证逻辑",
    "复现测试失败"
  ],
  "current_step": "修改 password validation",
  "open_questions": [],
  "artifacts": [
    "tests/test_auth_empty_password.py"
  ]
}

11.2 你的 Agent 有没有 progress log

长任务一定要有进度记录，尤其是 coding agent、research agent、数据处理 agent。

progress log 应该记录：

• 做过什么；
• 为什么这么做；
• 哪些尝试失败了；
• 当前卡在哪里；
• 下一步是什么；
• 哪些文件或结果很重要。

11.3 你的工具返回是不是太啰嗦

很多 Agent 失败，就是因为信息太多。工具返回要尽量：

• 短；
• 准；
• 结构化；
• 可引用；
• 可追溯。

比如搜索代码时，不要直接返回整个文件。

更好的返回是：

{
  "matches": [
    {
      "file": "src/auth/service.py",
      "line": 87,
      "snippet": "if password is None: return True"
    }
  ],
  "total": 1
}

需要完整文件时，再让模型按需读取。

11.4 你的 Agent 有没有 checkpoint

只要 Agent 能修改环境，就应该有 checkpoint。

• 对于 coding agent，最简单的 checkpoint 就是 git commit 或 git stash。
• 对于数据处理 agent，checkpoint 可以是中间表、任务快照、文件版本。
• 对于业务流程 agent，checkpoint 可以是状态机节点。

如果没有 checkpoint，失败后只能靠模型自己解释发生了什么，非常不可靠。

11.5 你的 Agent 有没有终止条件

很多 Agent 会陷入一种很尴尬的状态：一直尝试，一直修，一直觉得还差一点，但其实是陷入死循环了。

所以必须有终止条件，比如：

• 最多执行 N 轮；
• 最多调用 N 次工具；
• 连续 N 次测试失败后暂停；
• 成本超过阈值后暂停；
• 遇到权限问题必须请求用户；
• 成功通过指定验证后结束。

11.6 你的 Eval 看的是结果，还是只看回答

• 一个客服 Agent 说「退款已处理」，不代表数据库里真的有退款记录。
• 一个 coding Agent 说「测试通过」，不代表它真的跑了完整测试。
• 一个数据分析 Agent 说「结论可靠」，不代表 SQL 没写错。

所以 Eval 要尽量看 outcome，而不是只看文本，比如：

Agent 类型	更可靠的 Eval
coding agent	单元测试、集成测试、静态分析、diff 检查
数据分析 agent	SQL 校验、结果抽样、指标对账
客服 agent	工单状态、退款记录、用户满意度
浏览器 agent	页面状态、后台数据、操作轨迹
Research agent	来源覆盖、引用质量、事实一致性

11.7 高风险动作有没有权限边界

如果你的 Agent 可以执行这些动作，就一定要有审批或限制：

• 删除文件；
• 修改生产数据；
• 发送外部消息；
• 调用支付接口；
• 访问敏感文档；
• 提交代码；
• 部署服务；
• 调用外部网络；
• 执行任意 shell。

权限设计不是上线前才补的东西，它应该从第一版 Harness 就存在，哪怕最开始只是一个简单的 allowlist，也比完全不管强。

12. 常见误区

误区一：Agent 做不好就是 Prompt 没写好

Prompt 确实可能有问题，但 Agent 做不好，也可能是：上下文错了、工具错了、反馈错了、验证错了、权限错了、状态管理错了。不要把所有问题都归因到 Prompt，这会让你在错误的层面上反复调参。

误区二：Context 越长越好

长上下文是能力，不是策略。真正重要的是高信噪比上下文。

对于 Agent 来说，很多信息应该留在外部，通过工具按需读取。而不是所有东西都要进模型当前窗口。

误区三：工具越多越好

工具越多，选择成本越高，歧义越多，权限风险越大，上下文也越容易膨胀。好的 Agent 工具集通常是少而清晰的，每个工具都有明确职责、结构化返回和可控权限。

误区四：Eval 就是测模型

Eval 测的是模型、Prompt、Context、Tools、Harness、Runtime 的组合，你换了任何一层，结果都可能变。

所以不要只说某个模型通过率多少，要说它在什么 harness、什么工具、什么数据集、什么权限和什么评估标准下表现如何。

误区五：模型变强后 Harness 就不重要了

模型变强后，某些复杂 Prompt 技巧可能会失去必要性。但模型越能行动，越需要边界、审计、验证和恢复，能力越强，系统设计越重要。

13. 总结

Agent 工程正在发生一个很重要的变化。

早期我们关注的是：

怎么写一个更好的 Prompt，让模型给出更好的答案。

现在真正重要的问题变成了：

怎么设计一个更好的系统，让模型能持续、可靠、安全、可验证地完成任务。

这就是从 Prompt 到 Harness。Prompt 仍然重要，但它不再是全部。

在 Agent 场景里，真正拉开差距的，往往是：

• 你怎么组织上下文；
• 你怎么设计工具；
• 你怎么保存状态；
• 你怎么处理失败；
• 你怎么做 checkpoint；
• 你怎么验证结果；
• 你怎么控制权限；
• 你怎么留下 trace；
• 你怎么让系统能被调试、被复现、被迭代。

所以未来优秀的 Agent 开发者，不会只是「会调 Prompt 的人」。更像是这样一种工程师：

• 理解模型能力，也理解系统边界。
• 知道什么时候应该相信模型，也知道什么时候必须验证模型。
• 会给模型自由度，也会给它轨道、刹车和仪表盘。

这才是 Agent 真正进入工程化阶段的标志：不是让模型看起来像一个聪明人，而是让模型成为一个可以被部署、被约束、被衡量、被持续改进的系统组件。

从这个角度看，Prompt 到 Harness 不是一个新名词的变化，它更像是 AI 应用开发从玩具走向工程的分界线。