从 Prompt 到 Harness：为什么企业级 Agent 一上线，就暴露出另一套测试与架构难题？
很多人已经开始感觉到，AI Agent 的风向变了。
前两年，大家讨论最多的是 Prompt 怎么写、模型怎么选、知识库怎么接。只要能让大模型调用一个工具、生成一段代码、完成一次页面操作，就足以做出演示效果。
现在，企业真正关心的问题变成了：
Agent 能不能连续执行十几个步骤？
中途失败后，能不能从断点继续？
调用了哪些系统，修改了哪些数据，能不能完整追溯？
模型换了、工具升级了、业务规则变化了，原来的 Agent 会不会直接失控？
对于软件测试从业者来说，这种变化尤其明显。
过去测试一个 AI 应用，可能只需要检查回答是否准确、格式是否符合要求。现在面对企业级 Agent，还要测试任务规划、工具调用、状态流转、上下文管理、权限边界、失败恢复和多智能体协作。
这已经不是一个“模型效果问题”。
它正在变成一个完整的软件工程问题。
Prompt 依然重要，但 Prompt 只能告诉模型应该做什么。真正决定 Agent 能不能进入生产环境的，是围绕模型建立起来的那套运行环境。
这套运行环境，正在被越来越多团队称为 Harness。
目录
-
一、Agent 演示很惊艳，上线后却开始失控
-
二、企业要的不是“会回答”，而是“可靠执行”
-
三、Prompt、Context、Harness 到底分别解决什么
-
四、一个测试用例 Agent，为什么会越跑越不稳定
-
五、企业落地 Agent，需要补齐哪些工程能力
-
六、Agent 的下一轮竞争，可能发生在模型之外
一、Agent 演示很惊艳，上线后却开始失控
1. 能完成一次任务，不代表能稳定完成一类任务
一个典型的 Agent Demo 通常并不复杂。
用户输入一句需求，模型识别意图，调用几个工具，最后生成一个结果。
例如：
读取需求文档
→ 提取功能点
→ 生成测试用例
→ 导出 Excel
整个流程只有三四步，输入数据也不大。在这种条件下，即使系统没有复杂的状态管理、上下文压缩和异常恢复，也可能顺利跑通。
但企业场景不会一直这么简单。
真实任务可能是：
读取需求文档
→ 检索历史需求
→ 查询业务规则
→ 提取功能点
→ 识别接口变化
→ 分析影响范围
→ 生成测试点
→ 生成接口用例
→ 生成 UI 用例
→ 检查覆盖率
→ 去除重复用例
→ 调用测试平台
→ 创建测试计划
→ 通知相关负责人
当任务从 4 步增长到 15 步，问题不会线性增加。
它会成倍放大。
模型需要记住更多数据，处理更多工具结果，维护更多中间状态，还要保证前后步骤使用的是同一组业务口径。
任何一个环节发生偏差，都会影响后续链路。
第 3 步拿错了接口版本，第 8 步生成的测试用例可能全部基于过期字段；第 10 步没有识别这个错误，第 12 步仍然可能成功创建测试计划。
从系统角度看，任务执行成功了。
从业务角度看，整个结果却是错的。
2. Agent 越跑越不稳定，往往不是模型变笨了
很多团队会遇到一个很相似的现象：
同一个 Agent，执行三五步时表现很好；执行十几步之后，工具参数开始出错，前面发现的信息开始遗忘，最终结果逐渐偏离任务目标。
最直接的判断通常是：模型能力不够。
于是团队开始换更大的模型、购买更长的上下文窗口，或者在 Prompt 中加入更多规则。
但模型升级以后，问题往往只被推迟，并没有真正消失。
原因在于，Agent 每执行一步，都会向上下文中加入新的内容：
-
模型推理结果
-
工具调用参数
-
工具返回数据
-
错误信息
-
重试记录
-
中间分析结论
一个接口返回几十 KB 的 JSON 并不罕见。
如果系统把这些结果完整塞进上下文，几轮工具调用之后，真正与当前任务有关的信息可能只占很小一部分。
模型看到的内容越来越多，但有效信息的比例越来越低。
它不是没有信息，而是找不到重点。
上下文窗口越大，不代表 Agent 的有效记忆越强。没有信息治理的长上下文，只会形成更大的噪声场。
当模型因为噪声调用错工具，系统又会产生新的报错和重试信息。
上下文继续膨胀，模型下一轮判断进一步下降。
于是形成一个自我恶化的循环：
这类问题不是继续优化某一句 Prompt 就能解决的。
3. 测试人员会最早碰到 Agent 的工程边界
研发看到的是 Agent 能不能完成任务。
测试更容易看到另外一面：
-
相同输入多次执行，结果是否一致
-
某个工具超时后，任务是否还能继续
-
用户关闭页面后，后台任务是否丢失
-
调用失败时，Agent 会不会无限重试
-
上一步返回 20 条数据，下一步是否真的处理了全部数据
-
Agent 是否调用了未授权工具
-
业务规则变化后，旧知识是否仍在生效
-
任务成功状态是否等于业务结果正确
传统接口测试关注输入、处理和输出。
Agent 测试还需要关注过程。
因为 Agent 的结果不是由一段确定性代码直接计算出来的，而是由模型推理、工具调用、上下文数据和运行时状态共同决定的。
同一个最终结果，可能经过完全不同的执行路径。
其中一条路径安全、稳定、成本可控；另一条路径可能调用了十几次无效工具，只是碰巧得到了正确答案。
如果只验证最终输出，很多风险根本不会被发现。
企业级 Agent 的质量对象，不只是最终答案，还包括整个决策与执行链路。
二、企业要的不是“会回答”，而是“可靠执行”
1. AI 应用正在从内容生成转向任务执行
普通聊天机器人主要生成内容。
它可以回答问题、总结文档、改写文章。即使回答不够理想，用户通常还可以修改、重试或者直接放弃。
Agent 不一样。
Agent 会对外部系统产生真实影响。
它可能：
-
创建测试任务
-
修改数据库记录
-
提交代码
-
操作浏览器
-
调用生产接口
-
发送通知
-
调整业务配置
-
触发自动化流水线
一旦系统开始执行动作，质量标准就发生了变化。
内容生成允许概率性。
生产执行必须受到确定性约束。
模型可以不确定，但系统不能把这种不确定性原封不动地传递给生产环境。
企业真正需要的不是一个“更会思考”的聊天机器人，而是一个能够被控制、被恢复、被审计的任务执行系统。
2. Agent 的核心矛盾，是概率推理与确定执行之间的冲突
大模型适合处理模糊问题。
例如：
-
用户真正想解决什么问题
-
一份需求文档有哪些潜在风险
-
当前异常可能与哪些因素有关
-
下一步应该调用哪个工具
但大模型并不擅长精确搬运数据。
例如上一步工具返回：
{
"executionId": "9f82c48e-7b31-4d47-a62f-719c0d2d3821",
"caseCount": 128,
"status": "READY"
}
下一步需要用 executionId 查询执行详情。
最脆弱的做法，是让模型从历史消息中找到这个 ID，再复制到新的工具参数里。
长链路中，模型可能：
-
漏掉部分字符
-
混淆两个相似 ID
-
使用上一次执行的 ID
-
在压缩上下文后重新生成一个不存在的 ID
这类操作不需要推理能力，却消耗了大量模型注意力。
更合理的设计是：
步骤 A 的 executionId
↓
系统变量表
↓
参数绑定
↓
步骤 B 的 executionId 参数
数据由系统精确传递。
模型只负责决定是否需要调用步骤 B。
这背后是一条很重要的工程边界：
让模型负责理解、规划与判断，让系统负责状态、数据与约束。
当职责没有分开时，团队就会不断增加 Prompt，希望模型不要犯错。
当职责分开后，很多错误会从设计上直接消失。
3. 从 Prompt 到 Harness，本质是控制权逐渐回到系统
Agent 的工程演进大致可以分为三个阶段。
Prompt 工程解决的是指令问题。
Context 工程解决的是信息问题。
Harness 工程解决的是运行问题。
它们不是互相替代，而是逐层叠加。
Prompt 写得再好，也不能完成断点恢复。
Context 管理得再精细，也不能自动提供权限控制和执行审计。
Harness 的作用，就是把模型放进一套完整的工程环境中，让模型的能力能够稳定转化为业务结果。
三、Prompt、Context、Harness 到底分别解决什么
1. Prompt 工程解决“模型应该怎么做”
Prompt 是 Agent 最早的一层控制面。
一个结构化 Prompt 通常会包含：
-
角色与目标
-
任务边界
-
工具说明
-
输出格式
-
行为规则
-
示例数据
-
异常处理要求
在简单场景中，Prompt 非常有效。
例如要求模型：
你是一名资深测试工程师。
请根据需求文档提取功能点，并按照以下字段生成测试用例：
用例标题、前置条件、执行步骤、预期结果、优先级。
禁止生成需求中不存在的功能。
这已经能明显提升生成质量。
随着业务规则增加，System Prompt 可能从几百字增长到几千字，甚至发展成项目级说明文件。
里面可能包含代码路径、接口规范、发布规则、工具约束和业务术语。
这种做法的问题在于：无论当前任务是否需要，所有内容都会被注入上下文。
规则越多，Prompt 越长。
Prompt 越长，模型越难判断当前最重要的约束是什么。
工程师往往会继续加入：
IMPORTANT
MUST
DO NOT
CRITICAL
这些强调在短任务中有效，在长链路中却会逐渐被新的信息淹没。
真正的企业规则不能只停留在“提醒模型遵守”。
权限限制、字段校验、数据格式、审批条件和工具白名单，都应该由系统强制执行。
Prompt 可以表达规则。
系统必须落实规则。
2. Context 工程解决“模型当前应该看到什么”
很多人理解 Context Engineering，只是把更多业务资料塞给模型。
实际上，Context 工程的核心不是增加信息，而是控制信息。
一个成熟的上下文系统需要回答四个问题：
-
哪些信息必须进入当前上下文？
-
哪些信息只需要保留摘要？
-
哪些原始数据应该放在外部存储中？
-
后续需要细节时，如何准确取回？
可以把 Agent 的上下文管理设计成四层。
第一层：大结果外置
当工具返回大量 JSON、日志或文档时，不直接全部放进 Prompt。
系统把原始结果存入数据库或对象存储，只在上下文中保留：
{
"refId": "artifact_1024",
"type": "api_result",
"count": 238,
"summary": "共返回238条接口变更记录，其中17条影响核心交易链路"
}
模型需要查看细节时，再按引用读取。
第二层：语义压缩
对于当前任务需要理解、但不需要完整保留的数据，可以压缩为高密度信息。
压缩的重点不是“把文字变短”，而是保留后续步骤需要的关键事实：
-
ID
-
数量
-
状态
-
时间
-
风险项
-
未解决问题
-
已失败方案
第三层：对话整理
当历史消息持续增长时，不能简单删除最早内容。
更合理的做法，是生成一份结构化交接记录：
原始目标：
为支付系统版本 V3.8 生成回归测试计划。
已经完成：
- 已解析需求文档
- 已识别 12 个接口变化
- 已定位 3 个高风险交易链路
关键数据：
- requirementId：REQ-2381
- executionId：EXE-8832
已经失败的方案：
- 旧版 Swagger 文档字段不完整，停止使用
待处理：
- 生成支付失败补偿场景
- 检查幂等性测试覆盖
这样的内容比自由文本摘要更适合继续执行。
第四层：按需恢复
上下文压缩后，原始数据仍然不能丢失。
系统需要提供查询能力：
查看结构：outline(refId)
搜索字段：search(refId, query)
读取局部：context(refId, anchor)
读取完整数据：get(refId)
模型每次只获取当前步骤真正需要的信息。
Context Engineering 不是让模型记住所有内容。
它是让模型在正确的时间，只看到正确的信息。
3. Harness 工程解决“任务如何可靠地完成”
Harness 直译有“驾驭装置”“安全带”“控制系统”的含义。
放在 Agent 工程中，它不是某一个框架或工具，而是一整套围绕模型运行的基础设施。
一个企业级 Agent Harness，通常需要包含以下能力。
有状态执行
系统要知道：
-
当前执行到了哪一步
-
哪些步骤已经完成
-
中间结果存在哪里
-
哪些工具调用失败了
-
当前是否正在等待人工审批
状态不能只存在模型的对话历史中。
它需要被持久化。
断点恢复
一个 20 步任务在第 17 步失败，不应该重新执行前面的 16 步。
系统需要在关键节点保存检查点：
LLM 推理完成
→ 保存状态
工具调用完成
→ 保存状态
步骤完成
→ 保存状态
服务重启、网络中断或者外部系统超时后，可以从最近检查点继续。
事件溯源
每一次状态变化都应该记录为事件：
TASK_STARTED
PLAN_CREATED
STEP_STARTED
TOOL_CALLED
TOOL_SUCCEEDED
STEP_COMPLETED
TASK_PAUSED
TASK_RESUMED
TASK_FINISHED
前端展示、故障恢复、日志审计和成本分析都可以基于同一条事件流构建。
参数绑定
步骤之间的数据关系需要显式声明。
step: query_execution_detail
parameterBindings:
executionId:
sourceStep: create_execution
sourcePath: output.executionId
模型不再负责复制 ID。
运行时直接从上一步结果中读取并注入。
动作空间治理
工具越多，不代表 Agent 越强。
假设一个 Agent 同时暴露 80 个工具，每次规划时，模型都需要判断应该选择哪一个。
工具名称相似、能力重叠或说明不清晰时，误调用概率会明显增加。
更好的方式是根据任务阶段动态暴露工具。
需求分析阶段只提供文档解析与知识检索工具。
测试设计阶段再提供用例生成、覆盖率分析工具。
执行阶段才开放测试平台、浏览器和接口调用能力。
安全与权限
生产级 Harness 至少要具备：
-
工具白名单
-
参数 Schema 校验
-
高风险操作审批
-
最大执行步数
-
最大递归深度
-
重复调用检测
-
敏感信息脱敏
-
用户主动取消
-
资源与 Token 预算控制
这些能力不是为了让模型变得更保守。
它们的作用是把模型可能产生的不确定性限制在可控范围内。
4. Harness 的核心，不是给模型增加更多限制
早期 Agent 系统容易进入一种“防御式开发”。
模型经常传错参数，于是增加参数修复。
模型可能丢失字段，于是增加字段恢复。
模型可能重复调用，于是加入更多 Prompt 提醒。
最后，工具执行器的大量代码都在猜测模型哪里可能出错。
这类兜底机制在早期有价值，但不能无限扩张。
更好的方向不是持续修复错误，而是重新设计流程，让错误没有发生的必要。
例如：
|
防御式设计 |
Harness 设计 |
|---|---|
|
提醒模型不要写错 ID |
系统自动绑定 ID |
|
提醒模型不要无限重试 |
运行时限制最大次数 |
|
猜测模型是否完成任务 |
提供明确的步骤状态协议 |
|
把所有工具都交给模型 |
根据阶段动态开放工具 |
|
出错后从头执行 |
检查点与断点恢复 |
|
依赖模型记住历史经验 |
把经验写入结构化记忆 |
好的 Harness 不是不断告诉模型“不要犯错”，而是让正确路径比错误路径更短。
5. 企业级 Agent 已经接近一种新的运行时架构
当状态管理、上下文管理、工具系统、事件流、权限、记忆和评测被整合在一起时，Agent 系统就不再只是一个模型调用服务。
它更像一个轻量级操作系统。
模型只是其中的推理内核。
真正决定系统可靠性的，是外围架构。
四、一个测试用例 Agent，为什么会越跑越不稳定
1. 看起来简单的任务，内部可能有十几个状态节点
假设团队要开发一个“需求到测试用例”的 Agent。
用户上传 PRD 后，系统需要完成：
-
识别需求版本。
-
提取业务模块。
-
检索历史需求与缺陷。
-
查询测试规范。
-
提取功能点。
-
识别异常流程。
-
生成测试场景。
-
生成详细用例。
-
检查需求覆盖率。
-
删除重复用例。
-
评估风险等级。
-
导出测试平台格式。
-
创建测试任务。
最初的实现可能是一个大 Prompt：
请阅读需求文档，结合历史缺陷和测试规范，
生成完整测试用例并导入测试平台。
模型可以完成一部分工作。
但只要数据量和流程复杂度增加，问题就会出现。
2. 纯 Prompt 方案的问题，不止是生成质量
历史数据把上下文塞满
历史需求、缺陷记录、接口文档和业务规范可能达到几十万字。
全部注入，模型无法聚焦。
只注入一部分，又可能漏掉关键规则。
中间数据被模型改写
需求解析阶段识别出 36 个功能点。
到了用例生成阶段，模型可能只处理其中 20 多个，因为它在长上下文中自动做了信息压缩。
最终生成的用例格式完整，但覆盖率不足。
任务失败后无法恢复
系统已经完成需求解析、知识检索和测试点生成。
创建测试任务时，测试平台接口超时。
如果没有状态持久化，只能重新执行整个流程。
结果正确但过程不可接受
Agent 最终生成了测试用例，但中间可能：
-
检索了错误版本的业务规范
-
调用了不必要的生产接口
-
重复请求测试平台
-
泄露了敏感字段
-
消耗了远超预算的 Token
只检查最终 Excel，无法发现这些问题。
3. Harness 方案会怎样改造这条链路
把任务拆成可检查的步骤
每个步骤都定义：
-
输入
-
输出
-
使用工具
-
验收标准
-
失败策略
-
是否需要人工确认
用系统传递确定性数据
需求 ID、文档版本、功能点列表、接口 ID 通过 State 和参数绑定传递。
模型不负责复制。
用引用管理大数据
完整需求和历史缺陷存储在外部。
上下文中只保留摘要、索引和当前步骤需要的局部内容。
每一步都可以评测
例如“功能点提取”步骤的验收条件可以是：
需求章节覆盖率 >= 95%
功能点必须保留原始需求引用
不得生成需求中不存在的业务能力
未达到条件时，只重试当前步骤。
用检查点保存执行状态
测试平台接口失败后，从创建任务步骤继续执行。
前面的需求分析和用例生成结果不需要重新计算。
4. 两种方案的差距会随着任务复杂度扩大
|
对比维度 |
纯 Prompt Agent |
Harness Agent |
|---|---|---|
|
任务规划 |
模型临时生成 |
结构化计划与动态调整 |
|
数据传递 |
依赖上下文记忆 |
State 与参数绑定 |
|
大数据处理 |
全量注入或简单截断 |
外置存储、摘要、按需读取 |
|
异常恢复 |
通常从头重试 |
步骤级检查点恢复 |
|
工具权限 |
主要依赖 Prompt 提醒 |
运行时白名单与审批 |
|
过程验证 |
关注最终结果 |
每一步均可验证 |
|
执行审计 |
对话日志为主 |
结构化事件链路 |
|
成本控制 |
执行后统计 |
调用前预算与运行时限额 |
|
经验积累 |
新会话重新开始 |
结构化记忆与知识更新 |
|
适合场景 |
演示、短任务 |
长任务、生产业务 |
小任务中，两种方案看起来差距不大。
任务越长、工具越多、业务风险越高，差距越明显。
五、企业落地 Agent，需要补齐哪些工程能力
1. 不要从“做一个万能 Agent”开始
很多 Agent 项目一开始就希望接入几十个工具，覆盖多个业务系统，让模型自己规划一切。
这种方式很容易做出 Demo，却很难形成稳定产品。
更合适的起点，是一个边界清晰、结果可验证的业务闭环。
例如：
需求文档
→ 测试点生成
→ 人工评审
→ 导入测试平台
或者：
失败日志
→ 异常分类
→ 相似缺陷检索
→ 定位建议
→ 人工确认
先把一个流程做到：
-
输入明确
-
工具可控
-
结果可验
-
失败可恢复
-
成本可计算
再逐渐增加能力。
2. 把成功标准从“能跑通”改成“可重复”
Agent 第一次成功执行，证明的是可能性。
连续执行 100 次，才开始证明稳定性。
团队至少需要观察：
-
任务成功率
-
步骤成功率
-
工具调用正确率
-
平均重试次数
-
平均执行时长
-
Token 消耗
-
人工接管率
-
结果验收通过率
-
断点恢复成功率
-
高风险操作拦截率
对测试团队来说，Agent 的测试对象也需要从单轮问答扩展到完整运行链路。
3. 测试策略要从“输入输出”升级为“分层验证”
Agent 系统可以按照五层进行测试。
模型层
关注模型在特定任务中的基础能力：
-
意图识别
-
结构化输出
-
规划质量
-
事实准确性
-
幻觉率
Prompt 与 Context 层
关注输入信息是否正确：
-
是否召回正确知识
-
是否遗漏关键规则
-
是否存在冲突上下文
-
压缩后是否丢失关键 ID
-
是否出现上下文污染
Tool 层
关注模型与外部系统之间的交互：
-
工具选择是否正确
-
参数是否符合 Schema
-
返回异常是否正确处理
-
幂等性是否得到保障
-
超时和限流是否有效
Runtime 层
关注长任务运行质量：
-
状态是否正确持久化
-
检查点是否可恢复
-
重试是否会重复产生副作用
-
并行任务是否存在数据竞争
-
多 Agent 状态是否一致
业务层
关注结果是否真正创造价值：
-
测试用例覆盖率是否提升
-
缺陷定位时间是否下降
-
人工审核成本是否减少
-
错误操作风险是否可接受
-
Agent 是否遵守真实业务规则
只做模型评测，无法证明 Agent 可以上线。
只做功能测试，也无法解释 Agent 为什么失败。
4. 可观测性必须早于自进化
很多团队很早就开始讨论 Agent 自学习、自反思和自动优化。
但系统连基本执行数据都没有记录时，自进化没有可靠基础。
在增加自动学习之前，至少要能够回答：
-
哪个步骤失败最多
-
哪个工具最容易被误调用
-
哪种输入最容易导致计划偏离
-
哪个 Prompt 版本表现更好
-
哪种上下文压缩造成了信息丢失
-
人工为什么拒绝 Agent 的建议
没有这些数据，所谓自我优化只是让模型根据不完整信息继续生成新的规则。
更稳妥的顺序是：
可观测
→ 可评测
→ 可归因
→ 可修正
→ 灰度验证
→ 逐步生效
5. 不同阶段的从业者，需要建立不同的能力重点
在校生：先看懂完整链路
不需要一开始就研究复杂多 Agent 框架。
先理解 Agent 的基本组成：
模型 + Prompt + Context + Tool + Memory + Runtime + Evaluation
能够解释每个组件解决什么问题，比背诵十几个框架名称更重要。
初级工程师：从一个闭环场景开始
重点掌握：
-
Prompt 结构化设计
-
工具调用
-
RAG 与知识检索
-
状态管理
-
基础 Agent 评测
-
一个真实业务流程的完整实现
不要只做聊天机器人。
至少做一个能够读取数据、调用工具、输出结果并处理异常的 Agent。
中级工程师：能力重点会转向 Harness
需要继续补齐：
-
Agent Runtime
-
工作流与 ReAct 的组合
-
Context 生命周期管理
-
事件驱动与状态机
-
断点续传
-
权限与安全边界
-
多 Agent 协作
-
评测与反馈闭环
-
成本和稳定性治理
到了这个阶段，模型调用代码反而只是很小的一部分。
真正的难点，是如何把概率性的模型放进确定性的企业系统。
六、Agent 的下一轮竞争，可能发生在模型之外
1. 模型差距会缩小，工程差距会扩大
模型能力还会继续提升。
工具调用会更准确，长上下文会更稳定，推理成本也可能继续下降。
但这些变化不会自动让企业 Agent 变得可靠。
模型越强，企业反而越愿意把更复杂、更高风险的任务交给它。
任务复杂度增长之后，对运行时的要求也会同步提高。
过去，一个 Agent 只生成测试用例。
未来，它可能读取需求、分析代码变化、选择回归范围、生成脚本、执行测试、分析失败、提交缺陷并推动修复。
模型能力提升的结果，不是 Harness 变得不重要。
而是 Harness 需要承载更大的执行责任。
2. Agent 测试会成为新的质量工程方向
传统测试解决的是确定性系统中的缺陷。
Agent 测试需要面对概率性决策、动态路径和外部工具副作用。
测试方法会逐渐从固定用例，扩展到：
-
轨迹评测
-
工具调用评测
-
多轮任务评测
-
长上下文退化测试
-
对抗性指令测试
-
记忆污染测试
-
权限越界测试
-
断点恢复测试
-
多 Agent 协同测试
-
线上反馈回放
测试人员不会因为 Agent 出现而失去价值。
相反，系统越自主，越需要独立的质量保障机制。
只不过测试对象正在从一个接口、一个页面，变成一条包含推理和行动的动态执行链。
3. 企业 Agent 最终会走向认知与执行分离
未来复杂 Agent 系统可能逐渐分成两部分。
一部分负责认知：
-
理解目标
-
检索知识
-
生成计划
-
分析结果
-
做出建议
另一部分负责执行：
-
操作浏览器
-
调用接口
-
执行脚本
-
修改数据
-
收集证据
认知层可以使用更强的推理模型。
执行层强调确定性、隔离性和可恢复性。
两者通过结构化任务协议连接：
任务目标
+ 执行约束
+ 可使用能力
+ 验收标准
+ 风险等级
这种分离可以避免推理模型直接控制所有生产资源，也让模型和执行环境能够独立升级。
4. “会写 Prompt”会逐渐变成基础能力
Prompt 不会消失。
但它会像 SQL、接口设计或单元测试一样，成为完整工程体系中的一个组成部分。
未来更有价值的能力是：
-
能否把业务流程拆成可执行步骤
-
能否设计高质量的 Agent 工具
-
能否管理长链路上下文
-
能否建立确定性的数据传递机制
-
能否设计状态机和失败恢复
-
能否构建 Agent 评测体系
-
能否建立权限、审计和治理闭环
未来真正稀缺的，不是会调用大模型的人，而是能把 Agent 纳入架构、测试与治理体系的人。
当一个团队仍然依赖更长的 Prompt、更多的警告词和更大的模型来维持 Agent 稳定时，它可能还停留在 Demo 阶段。
当任务状态、上下文、工具、权限、评测和失败恢复都被显式设计时，Agent 才真正开始接近企业级系统。
回到你现在正在开发或测试的 Agent：
它只是能够把任务跑完，还是已经具备失败可恢复、过程可追溯、结果可验证的反馈闭环？
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
0
0- 0
已为社区贡献18条内容
所有评论(0)