先说结论
标题里的「已死」，指的是「只卷 Prompt、不补 Harness」那条路------不是 Prompt 本身。
Prompt 不会消失，它是 Harness 的地基。
System Prompt、工具描述、Few-shot、Cursor Rules------这些都是 Prompt，也永远是 Agent 最先接触的一层：告诉模型「你是谁、能干什么、不能干什么」。
但如果你的 Agent 要写进生产系统、要过合规审计、要跨 15 个决策节点跑完一笔 20 天的贷款流程------只调 Prompt 不够 。2026 年真正拉开差距的，是 Harness 工程：包裹在模型外面的整套「驾驭系统」------上下文怎么喂、工具怎么接、结果怎么验、错了怎么追溯。
一句话公式（Fowler 2026、arXiv 多篇论文都在用）：
Agent = Model + Harness
更准确的关系是：
Prompt ⊂ Guides ⊂ HarnessPrompt 是 Guides 的一部分；Guides 又是 Harness 的一部分。不是 Prompt 死了，而是 Prompt 从「全部」变成了「一层」。
模型决定智能的下限 ；Harness 决定执行的上限 。同一模型，只换一套 Harness，编程基准测试成功率可以从 42% 提到 78%------换模型的边际收益，未必比补全 Harness 更大。
一、血泪故事：AI 能读懂代码，却答不出「哪个定义才是对的」
我在金融项目里见过一个经典场景。
同一个 CRM，「客户状态」有三种写法：
- 两年前：
status: 0/1/2（小张写的，已离职） - 一年前：
customer_status: active/inactive（小李觉得更清晰） - 上周：AI 生成的营销页又冒出
user_state: 正常/冻结
PM 要做「客户健康度看板」，把三份代码丢给 AI------AI 全读懂了，却答不出：哪一个才是官方定义？
我管这叫语义腐败：不是普通技术债，是知识传承的系统性失效。
更可怕的是跨系统。一句业务需求：「交易成功且支付成功时，自动放款。」
- 交易 AI：
order_status = 2，非常自信 - 支付 AI：
pay_status = 'SUCCESS'，也非常自信 - 协调者：谁来定义统一查询？三个月后 AI 重构了代码，
order_status = 2含义变了，整条链路静默崩溃
审计追问：「为什么这笔钱在这个时点放出去了？」若答案是「两个 AI 协商后这么判的」------合规与运维都无法接受。
在金融行业，AI 的一次猜错，不是 Bug，是合规事故。
这类问题，加厚 Prompt 解决不了------因为 Prompt 里没有「官方 fieldId 是什么」这层事实，模型只能猜。
二、Harness 三层：Prompt 在哪一层？
Martin Fowler 2026 年 4 月的长文把 Harness 拆成 Guides（前馈） 和 Sensors（后验） 。结合自己的实践，我补成三层------第三层是国内团队最缺的：
| 层级 | 英文 | 做什么 | 典型实现 | Prompt 的关系 |
|---|---|---|---|---|
| 前馈 | Guides | 行动前约束方向 | Rules、SKILL.md、PRD 规范 | Prompt 主要在这一层 |
| 后验 | Sensors | 行动后校验结果 | lint、test、eval、脱敏检查 | 与 Prompt 无关，靠工程化 |
| 环境 | Context Pipeline | 行动时喂什么事实 | MCP、字段户口簿、Schema 包 | Prompt 替不了，必须外置 |
Cursor 自带了 Guides（含 Prompt/Rules）和部分 Sensors。
Context Pipeline------「AI 凭什么相信这些 fieldId 是对的」------几乎为零。
这就是很多团队的真实状态：Prompt 写得越来越长，返工率却没降下来。 根因不是 Prompt 写得不好，而是 Context 层空着，模型只能在充满歧义的代码库里「一本正经地推理」。
三、PPT 一页讲透：金融 AI 的 Harness 与语义底座
下面来自团队内部分享 PPT，四块内容对应 Harness 架构视角。
① Harness 决定了 AI 的上限
ini
AI Agent = 模型 + Harness- 模型 ：推理引擎，决定智能下限
- Harness ：驾驭系统，决定执行上限与最终结果
Harness 的核心作用：通过约束、反馈与验证，把模型间歇性的推理能力，组织成可持续运转的闭环。
同一模型、只换 Harness → 编程基准 42% → 78%。
② 金融行业需要什么样的 Harness？
一笔贷款从进件到资产管理：周期 20+ 天，跨越 15+ 关键决策节点。任何一步 AI 出错，都不是「再来一次」能解决的。
金融级 Harness 关注的不是吞吐（QPS），而是：
- 合规边界兜底
- 模型幻觉熔断
- 全流程可审计
落地大山 · 生产资料的「非标之痛」：
AI 需要强结构化、无歧义、机器可直接解析的数据（如严格 JSON Schema）。把金融机构海量「非标」资产清洗成「标准粮」，是需要几百人干上两三年的脏活累活。
销售说的「GMV」、财务说的「实收」、运营说的「成交额」，在数据库里可能是三个字段------AI 生成的计算口径全错。 这不是 Prompt 能「理解」出来的，需要 Context Pipeline 提供标准答案。
③ 户口簿与 Schema ------ Harness 的语义底座
| 组件 | Harness 定位 | 解决什么问题 |
|---|---|---|
| 字段户口簿 | 数据驾驭层 | 将 order_id / trans_no / serial_number 等别名，统一映射到标准业务概念「订单号」，让 AI 在正确语义上工作 |
| Schema 设计 | 上下文工程层 | 提供强结构化字段定义（类型、枚举、敏感等级、脱敏规则），让 AI「看得懂」数据 |
本质： 语义层是数据仓库与 AI 模型之间的智能翻译系统 ------ 标准化定义 · 一致性保障 · 错误隔离。
没有户口簿与 Schema，Harness 再精美，AI 也只能在充满错误和歧义的上下文里「一本正经地胡说八道」。
户口簿与 Schema 不是锦上添花 ------ 而是决定金融 AI 从「能用 」走向「敢用」的关键基础设施。
④ 量化价值 ------ 不是「好不好用」，是「能不能用」
（行业公开案例参考，非单一项目自测）
| 指标 | 变化 | 来源 |
|---|---|---|
| 财务报表生成准确率 | 68% → 92% | 某金融科技公司 |
| 数据工程师语义问题工时 | -75% | 同上 |
| AI 推荐字段映射准确率 | 80%+ | 头部金融机构贯标 |
| 人工复核工作量 | -70%+ | 同上 |
| 数据治理效率 | +120% | 江苏农商联合银行 |
| 单条数据处理时间 | 数十秒 → 数秒 | 同上 |
四、完整例子：6 字段链路里，Prompt 和 Harness 各干什么
以「大额转账 AML」为例：
css
PRD 原话
付款账号 · 付款人身份证 · 收款账号 · 转账金额 · 对手方国家 · 付款人风险等级
↓ Guides / Prompt
「禁止自造 fieldId，必须先调 standardize」
↓ Context Pipeline（MCP standardize_fields → 户口簿）
payer_account · id_number · payee_account · payment_amount
· counterparty_country · customer_risk_level
↓ Sensors（compile-schema 注入 ruleRefs / 脱敏 / api.submit）
↓ 代码产出
ms-form-dialog prop 全程 fieldId · toTarget 映射到 accounting 列名- Prompt 的作用：约束 Agent「不要猜字段名，去查户口簿」
- Harness 的作用 ：户口簿真的返回标准 fieldId，compile-schema 真的注入规则------事实与校验不在 Prompt 里，而在服务里
整条链路数据来自 01_domains/，没一条是 AI 现编的。
五、趋势：从 Model Scaling 到 System Scaling
arXiv 2026：From Model Scaling to System Scaling。
Agent 任务成功率的上限， increasingly 由 Harness 决定------memory、tool routing、verification loop、审计留痕。
下一战场三件事：
- Tool Interface 规模化 --- MCP 覆盖 Agent 主链路，不只 3 个 HTTP 工具
- Context Pipeline 外置 --- 语义从 Prompt 抽到可治理、可版本化的服务
- Sensors 工程化 --- eval gate 挡在 deploy 之前
Prompt 继续写，但别指望 Prompt alone 撑起生产级 Agent。
六、Harness 自检清单（可收藏）
- Guides / Prompt：CLAUDE.md 写清禁止自造字段名、必须查 MCP------这是地基，不能省
- Sensors：pre-commit lint + typecheck；关键路径 eval gate
- Context Pipeline ：接 MCP 或 REST
/resolve，别名 → fieldId 不靠猜 - Observability：Agent 查字段留日志，未命中走 missing 反馈
- 边界诚实：存量代码不会自动改；新产出自动对齐，存量走影响清单
结语
Prompt 工程教你怎么跟模型说话------这层永远需要。
Harness 工程决定模型能不能在你的系统里活着、敢不敢上线------这层 2026 年才开始被认真补。
金融场景的上限，往往卡在语义层：Guides 写得再漂亮，Context Pipeline 没有「对的标准」，Sensors 也无从验起。
我在做的字段户口簿，是 Harness 里 Context Pipeline 的数据驾驭层；Schema 是上下文工程层。Prompt 告诉 Agent「去查」；户口簿让它「查得到、查得对」。
你现在的 Agent 链路里，Context Pipeline 这一层是空的、还是已经接了 MCP / 语义服务？
评论区聊聊------尤其是「Prompt 写对了，fieldId 还是全错」那种坑。