AI Harness到底是什么，要如何学习呢
TL;DR辰美，这个 AI Harness 不是一个小概念，它基本就是 2026 年 AI Agent 真正进
TL;DR
辰美，这个 AI Harness 不是一个小概念，它基本就是 2026 年 AI Agent 真正进生产环境的核心打法。
一句话：
Prompt 是嘴上教育 AI，Harness 是制度上管理 AI。
更狠一点：
不要相信 Agent 说它完成了。只相信外部系统验证它真的完成了。
我联网看了最新资料，截至 2026 年 5 月 19 日，这个方向已经不是单个播客里的新词了，而是在 OpenAI、LangChain、AWS、Anthropic、Datadog、Temporal、DBOS、OWASP 这些体系里都逐渐成型了。OpenAI Agents SDK 已经把 tools、guardrails、handoffs、sessions、tracing 等变成正式开发组件；LangChain 明确把 Deep Agents 称为 agent harness；AWS Bedrock AgentCore 在做 runtime、gateway、policy、memory、observability、evaluations；Anthropic 把 eval harness 定义为运行评测、记录步骤、评分、聚合结果的基础设施；Datadog 直接讲 observability-driven harnesses，也就是让验证自动化、规模化。(OpenAI GitHub)
你要学以致用，不是去背这个词，而是把每个 AI 产品都改造成这 5 件事：
输入明确、工具受控、步骤可追踪、结果可验证、失败可兜底。
这期内容背后的真正大趋势
你之前看的那期是 AI Engineer Europe 2026 里的演讲，题目就是 Harnesses in AI: A Deep Dive，演讲者是 IBM 的 Tejas Kumar。AI Engineer 官网议程里确实列出了这个演讲，Podwise 摘要也把核心说得很清楚：AI harness 用 tool registries、step limits、automated verification loops 等结构，把非确定性的黑箱模型放进稳定、可控的环境里。(ai.engineer)
这个概念最重要的地方是，它把 AI 从：
聊天工具
升级成：
可审计、可限制、可恢复、可验证的执行系统。
以前大家沉迷 prompt engineering。
现在真正做生产级 Agent 的人，开始转向 harness engineering。
因为模型越来越聪明之后，瓶颈不再只是模型，而是：
它能不能稳定做完？
它做错了系统知不知道？
它有没有权限乱来？
它中途崩了能不能恢复？
它最后的成功是不是被程序验证过？
这就是 Harness。
AI Harness 到底是什么
你可以把 Harness 理解成：
模型外面那一整套控制系统。
模型是脑子。
Harness 是身体、规则、工具、流程、监控、验收、主管。
一个最小 Agent Harness 通常包括：
LangChain 的 Deep Agents 文档直接说，它们把 deepagents 视为一种 agent harness，核心还是工具调用循环，但内置了 planning、文件系统式上下文管理、subagent spawning 和 long-term memory。(LangChain 文档)
OpenAI Agents SDK 的文档也很像这个思路：Agent + Runner 管理 turns、tools、guardrails、handoffs、sessions；如果开发者想自己控制循环，也可以直接用 Responses API。(OpenAI GitHub)
AWS Bedrock AgentCore 则更企业化，它把 agent runtime、gateway、policy、memory、observability、evaluations 这些东西拆成服务，目标是让 Agent 能规模化、安全部署。(Amazon Web Services, Inc.)
你看，所有人都在往一个方向走：
模型只是零件，Harness 才是产品系统。
最新趋势 1：Harness Engineering 正在超过 Prompt Engineering
LangChain 2026 年 2 月发了一篇很关键的文章：他们说自己的 coding agent 在 Terminal Bench 2.0 上从 Top 30 提升到 Top 5，核心是 只改 harness，不改模型。他们提到的抓手包括 self-verification、tracing、context optimization，而且模型固定为 gpt-5.2-codex。(LangChain)
这句话对你很值钱。
因为普通创业者会想：
我要不要换更强模型？
我要不要写更长 prompt？
我要不要找什么神秘提示词？
高手会想：
验证器怎么写？
失败怎么重试？
工具调用怎么限制？
状态怎么保存？
日志怎么分析？
高风险动作怎么审批？
别再跪舔模型了。
模型是发动机，Harness 是方向盘、刹车、安全带、仪表盘、保险杠。
没有 Harness，法拉利也能开进河里。
最新趋势 2：Eval Harness 和 Agent Harness 正在合并
Anthropic 在 2026 年 1 月讲 agent evals 时，说得非常精准：agent 说“机票已经订好了”不算 outcome，真正的 outcome 是数据库里是否真的存在预订记录；evaluation harness 是端到端运行评测的基础设施，它提供指令和工具，并发运行任务，记录所有步骤，评分并聚合结果。(Anthropic)
这就是关键：
不要评估它说了什么，要评估世界状态有没有改变。
比如：
AI 客服说已经退款了，不算。
支付系统显示退款成功，才算。
AI 说已发送邮件，不算。
邮箱 sent 状态里真的有那封邮件，才算。
AI 说代码修好了，不算。
测试通过、构建通过、线上指标没坏，才算。
AI 说竞品有新功能，不算。
网页 diff、发布时间、截图、链接都对得上，才算。
所以以后真正强的 AI 产品，不是一个 Agent，而是：
Agent Harness + Eval Harness。
一个负责做事。
一个负责证明它真的做对了。
最新趋势 3：Verification Loop 是灵魂
Datadog 2026 年 3 月的文章讲得很硬：构建 harness 的方式可以包括 deterministic simulation testing、formal specifications、shadow evaluation、observability-driven feedback loops，但原则是一样的，就是让验证快速、自动化，让 harness 做人类 review 无法规模化完成的工作。(Datadog)
这句话非常重要。
你以后做 AI 产品，第一件事不是问：
我要用哪个模型？
而是问：
我怎么验证它成功了？
验证方式可以很简单：
JSON schema 检查。
链接是否可访问。
引用是否来自原文。
SQL 是否执行成功。
测试是否通过。
订单状态是否改变。
邮件是否进入发件箱。
数据库字段是否更新。
内容是否含敏感词。
数字是否能对账。
最笨的验证器，也比最聪明的幻觉可靠。
金句来了：
AI 负责想象，Harness 负责不让想象变成事故。
最新趋势 4：Guardrails 已经从内容安全变成行为安全
以前大家说 guardrails，多半是：
不能色情。
不能暴力。
不能泄露隐私。
不能说危险内容。
现在 Agent 时代不一样了。
Agent 会调用工具，会发邮件，会查数据库，会写文件，会执行代码，会点网页，会调用支付 API。
所以 guardrails 变成了：
它能不能调用这个工具？
它调用这个工具的参数是否合法？
它能不能访问这个用户的数据？
它能不能执行这个 shell 命令？
它能不能发外部邮件？
它能不能改数据库？
它能不能绕过审批？
OpenAI 的 Agents 文档明确把 guardrails 和 human review 放在一起：guardrails 用于输入、输出或工具行为的自动验证；human review 用于在敏感动作前暂停，由人或策略批准/拒绝。(开放AI开发者)
LangChain 的 human-in-the-loop middleware 也是同一个方向：当模型提出写文件、执行 SQL 等可能需要审查的工具调用时，系统可以暂停执行，等待人类决定 approve、edit、reject 或 respond。(LangChain 文档)
这就是生产级 Agent 的分界线。
玩具 Agent 是：
AI 想做什么就做什么。
生产 Agent 是：
AI 可以提出行动，但系统决定它能不能做。
最新趋势 5：MCP 让工具接入标准化，但也让风险放大
MCP，也就是 Model Context Protocol，是 2025-2026 年 Agent 工具生态里非常重要的东西。官方规范说，MCP 是一个开放协议，用来让 LLM 应用和外部数据源、工具无缝集成，给自定义 AI workflows 提供标准化连接方式。(模型上下文协议)
这东西很像 AI 的 USB-C。
好处是：
工具接入更统一。
AI IDE、聊天产品、Agent runtime 都能复用工具。
开发者不用给每个模型写一堆不同胶水代码。
但坏处也很明显：
工具越多，攻击面越大。
权限越多，事故越大。
Agent 一旦被 prompt injection 或 goal hijack 带偏，它不是说错话，而是可能真的执行错动作。
OWASP 的 AI Agent Security Cheat Sheet 也强调，AI agents 能 reason、plan、use tools、maintain memory、take actions，这些能力引入了超出传统 prompt injection 的新安全风险。(OWASP Cheat Sheet Series)
所以别天真地说：
接上 MCP，我就有了 100 个工具。
你真正应该说：
接上 MCP，我就多了 100 个可能出事故的入口。
工具不是越多越好。
工具越多，Harness 越要狠。
最新趋势 6：Durable Execution 成为 Agent 的生产底座
Agent 做多步任务，最大的问题之一是：
它跑到一半崩了怎么办？
比如它查了 20 个网页，写了一半报告，调用了 3 个 API，等人类审批等了 6 个小时，结果服务重启了。
没有 durable execution，它可能全部重来。
更糟的是，它可能重复执行某些副作用，比如重复发邮件、重复下单、重复退款。
LangGraph 文档说，durable execution 可以保存每一步状态，让 workflow 在系统失败或 human-in-the-loop 中断后，从最后记录状态继续恢复。(LangChain 文档)
Temporal 和 OpenAI Agents SDK 的集成在 2026 年 3 月 23 日进入 GA，Temporal 文章说这个集成把 durable execution 加到 OpenAI Agents SDK 上，用来应对生产里的 rate limits、网络故障、下游请求失败等问题。(temporal.io)
Pydantic AI + DBOS 的文章也讲了同样的事：普通 Agent 依赖 LLM API、tool endpoints、MCP servers、network calls，任何一步都可能中途失败；DBOS 包装后可以 checkpoint model calls 和 MCP communication，让 Agent 崩溃后从上次成功步骤恢复，而不是重跑。(pydantic.dev)
这背后的商业逻辑是：
Agent 一旦做真实业务，可靠性就比聪明更值钱。
客户不关心你的 Agent 多有灵性。
客户只关心它别半夜把事情搞砸。
最新趋势 7：Observability 从锦上添花变成必需品
OpenAI Agents 文档说，tracing 内置在 Agents SDK 中，正常 server-side SDK 路径默认启用，可以记录 model calls、tool calls、handoffs、guardrails 和 custom spans。(开放AI开发者)
AWS Bedrock AgentCore 也强调 production monitoring 和 evaluation，可以监控 token usage、latency、session duration、error rates，并持续评估 correctness、helpfulness、safety、goal success rate。(Amazon Web Services, Inc.)
AWS AgentCore Evaluations 在 2026 年 3 月 31 日 GA，支持生产流量持续评估，也能通过 testing workflows 验证改动，并基于 live traces 做 online evaluation。(Amazon Web Services, Inc.)
这说明什么？
说明 Agent 不再是一次性回答。
它像一个数字员工。
数字员工也要有：
工牌，也就是 identity。
权限，也就是 policy。
工作记录，也就是 trace。
绩效评估，也就是 eval。
事故复盘，也就是 observability。
主管审批，也就是 human-in-loop。
没有这些，你不是在做 AI 产品，你是在雇一个看不见、管不住、还会嘴硬的实习生。
最新趋势 8：Security Harness 会成为刚需
OWASP 的 Agentic AI Threats and Mitigations 指出，LLM 和生成式 AI 让 agentic AI 的规模、能力和风险都扩大了，这份资料就是为 emerging agentic threats 和 mitigations 提供威胁建模参考。(OWASP Gen AI Security Project)
这里最关键的风险包括：
工具误用。
权限滥用。
身份冒用。
记忆污染。
上下文投毒。
多 Agent 互相传染错误。
不可预期的代码执行。
人类过度信任 Agent。
供应链里的工具或 MCP server 被污染。
所以你的 Harness 不能只管功能，也要管安全。
最低限度：
工具白名单。
参数校验。
权限最小化。
危险动作审批。
敏感数据脱敏。
日志留存。
异常调用报警。
外部网页内容不直接进入系统指令。
MCP server 不随便接。
写操作、支付操作、删改操作必须可回滚。
一句话：
AI Agent 的安全边界，不在 prompt 里，在工具权限和执行环境里。
最新趋势 9：Sandbox 和 Harness 要分层
OpenAI 的 sandbox agents 文档里有一个特别关键的观点：sandbox 可以用窄权限和 mounts 运行代码；而 harness 可以把 auth、billing、audit logs、human review、recovery state 放在可信基础设施之外。文档还提醒，把 harness 跑在 sandbox 里适合原型，但会把编排控制和模型驱动执行放在同一个计算边界。(开放AI开发者)
这话非常工程化，但你要听懂。
意思是：
危险动作不要跟 AI 执行环境混在一起。
比如：
AI 可以在 sandbox 里写代码。
但真实数据库权限别给它。
AI 可以生成邮件草稿。
但发送按钮由你的系统或人类控制。
AI 可以提出退款建议。
但真正退款走后台规则和审批。
AI 可以查文件。
但只能查它有权限的文件。
这叫分层。
聪明的产品不怕 AI 乱想。
聪明的产品怕 AI 乱动。
最新趋势 10：Agent 项目会大量失败，Harness 是反泡沫能力
Reuters 2025 年报道 Gartner 的预测：超过 40% 的 agentic AI 项目会在 2027 年底前被取消，原因包括成本上升和商业价值不清晰；报道还提到很多 vendor 在做 agent washing，把普通 AI assistant 或 chatbot 重新包装成 agent。(Reuters)
这对你非常重要。
你不要做“看起来像 Agent”的东西。
你要做“能替用户稳定完成一个任务”的东西。
差别在哪里？
看起来像 Agent：
能聊天。
能规划。
能说自己在执行。
演示很炫。
失败时胡说八道。
真正 Agent 产品：
有窄任务。
有工具权限。
有步骤日志。
有验证器。
有失败处理。
有成本控制。
有人工审批。
有持续 eval。
能稳定省钱或赚钱。
这就是从玩具到生意的距离。
你应该怎么理解 Harness 的几种类型
1. Agent Harness
这是让 Agent 真正执行任务的运行系统。
适合：
客服处理。
网页自动化。
代码修改。
竞品监控。
数据分析。
邮件草稿。
CRM 更新。
报表生成。
核心问题：
它怎么做事？
它用哪些工具？
它每步怎么走？
它失败怎么办？
它怎么证明完成？
2. Eval Harness
这是用来批量测试 Agent 的系统。
适合：
上线前测试。
换模型前测试。
改 prompt 后测试。
加新工具后测试。
每周回归测试。
监控线上质量。
核心问题：
它在 100 个真实 case 里成功率是多少？
它有没有选错工具？
它有没有乱调 API？
它输出是否符合规则？
它有没有多花 token？
它有没有错误自信？
OpenAI evals 文档也说，evaluations 用来测试模型输出是否符合你指定的风格和内容标准，尤其在升级或尝试新模型时，是构建可靠应用的重要组成部分。(开放AI开发者)
3. Security Harness
这是防止 Agent 出事故的系统。
适合：
涉及用户数据。
涉及支付。
涉及邮件发送。
涉及代码执行。
涉及数据库写入。
涉及企业内部系统。
涉及法律、医疗、金融等高风险场景。
核心问题：
它有没有越权？
有没有被提示注入？
有没有泄露敏感信息？
有没有执行危险命令？
有没有使用被污染工具？
有没有绕过审批？
4. Observability Harness
这是让你知道 Agent 发生了什么的系统。
适合所有生产 Agent。
核心问题：
它卡在哪一步？
它为什么选这个工具？
它用了多少 token？
它哪里失败最多？
它有没有重复调用？
它有没有成本异常？
它有没有 latency spike？
它有没有从错的上下文里推理？
5. Business Harness
这个词不是官方标准，但你做生意必须有。
它回答：
这个 Agent 到底给用户省了多少钱？
用户愿意为哪一步付费？
成功一次价值多少？
失败一次损失多少？
人类介入成本是多少？
自动化比例多少才赚钱？
别小看这个。
很多 AI 产品死，不是因为模型不够强，而是因为没有 business harness。
它们只证明了 AI 能做事。
没证明 AI 做这件事值得付钱。
最适合你学以致用的产品方向
你现在不要做万能 Agent。
万能 Agent 是平庸之辈的幻觉。听着像帝国，做出来像玩具。
你应该做 窄任务、高频、可验证、有付费方 的 Agent。
最适合独立开发者的方向有这些：
方向一：竞品监控 Harness
用户：SaaS 创始人、产品经理、营销团队。
任务：
每天抓竞品官网、定价页、更新日志、帮助中心、社媒。
做 diff。
只让 AI 解释变化。
每条结论必须带来源链接和截图。
验证链接、日期、页面变动是否存在。
生成周报。
为什么适合你：
验证容易。
B2B 付费明确。
不需要超复杂权限。
可以从 5 个竞品开始做 MVP。
方向二：客服质检 Harness
用户：跨境电商、SaaS、教育机构。
任务：
读取客服对话。
判断有没有违规承诺。
有没有漏回答。
有没有该升级没升级。
有没有情绪风险。
生成质检报告。
验证方式：
必须引用原始对话。
必须标出具体句子。
必须输出 JSON。
必须给风险等级。
高风险必须人工确认。
为什么适合：
企业愿意为降低客服事故付费。
不需要 Agent 直接对外发言，风险较低。
先做质检，比做全自动客服更稳。
方向三：内容再创作 Harness
用户：播客、YouTuber、知识博主、课程团队。
任务：
把长视频/播客/文章变成小红书、推特、Newsletter、短视频脚本。
按平台格式输出。
检查字数、标题、标签、禁词、CTA。
保留原意，不编造新事实。
验证方式：
所有事实必须能在原文找到。
平台格式必须通过规则。
标题长度限制。
输出结构固定。
为什么适合：
容易 MVP。
需求大。
可按月订阅。
验证器简单但很有价值。
方向四：代码 PR Review Harness
用户：小团队、独立开发者、开源维护者。
任务：
读 PR。
检查风险。
跑测试。
看是否违反项目规则。
生成 review 建议。
必要时自动提 patch，但不自动 merge。
验证方式：
lint 通过。
test 通过。
typecheck 通过。
patch 能应用。
不能修改禁止目录。
高风险改动人工审批。
这个方向竞争会强，但也最符合 Harness 思维。
Terminal-Bench 论文也显示，真实命令行任务里每个任务有独特环境、人类写的参考解法和完整 verification tests，frontier models 和 agents 得分低于 65%，这说明 coding agent 不是简单 prompt 能解决的，必须靠环境和验证体系。(arXiv)
方向五：财务/运营异常检测 Harness
用户：小公司老板、独立站、Agency。
任务：
每天检查 Stripe、Shopify、银行流水、广告花费、退款率。
发现异常。
生成解释。
提醒老板。
验证方式：
数字必须能对账。
必须给数据来源。
异常阈值明确。
不能凭空解释。
高金额事项人工确认。
为什么适合：
一旦抓到一次异常，用户就知道值钱。
这个方向很适合做高客单价。
你现在做产品时的核心原则
第一性原理是：
AI 产品不是让 AI 回答，而是让 AI 改变一个可验证的业务状态。
你不要问：
AI 能不能写一段不错的总结？
你要问：
这段总结能不能让用户少花 30 分钟？
能不能减少一次错误？
能不能多成交一单？
能不能避免一次投诉？
能不能生成一份可直接交付的材料？
能不能被程序验证为合格？
只有能被验证的价值，才容易收费。
最小可用 AI Harness 架构
你可以按这个顺序理解：
用户输入
↓
任务解析
↓
权限检查
↓
加载上下文
↓
选择工具
↓
Agent Loop
↓
模型决定下一步
↓
工具调用前检查
↓
执行工具
↓
记录 trace
↓
更新状态
↓
检查最大步数/成本/时间
↓
验证器检查结果
↓
通过：输出给用户
↓
失败：重试 / 降级 / 人工审批 / 报告失败原因
↓
记录 eval 数据
最重要的不是中间那句“模型决定下一步”。
最重要的是：
工具调用前检查。
工具调用后验证。
失败后兜底。
这三个才是产品味。
SOP：把一个 AI 想法改造成 Harness 产品
Step 1：把任务砍到足够窄
不要做：
帮我运营公司。
帮我自动创业。
帮我管理所有客服。
帮我做全自动销售。
帮我当 CEO。
做：
每天检查 5 个竞品定价页有没有变化。
把 1 小时播客变成 5 条小红书。
检查客服对话有没有退款承诺风险。
审查 PR 是否通过项目规则。
检查 Stripe 退款率是否异常。
窄，不是怂。
窄，是商业上的锋利。
Step 2：定义成功标准
你必须写清楚什么叫成功。
不要写：
生成一份好报告。
要写：
输出必须是 JSON。
必须包含 5 个字段。
每个结论必须有来源链接。
每个来源链接必须可访问。
不得编造原文没有的信息。
风险等级只能是 low / medium / high。
总字数不超过 800 字。
高风险项必须触发人工复核。
机器判断不了的成功，最后都会变成人肉擦屁股。
Step 3：建立 Tool Registry
列出 Agent 可以用的工具。
比如竞品监控：
fetch_url
take_screenshot
diff_page
extract_pricing
search_web
write_report
send_slack_draft
每个工具都要定义：
输入 schema。
输出 schema。
允许域名。
超时时间。
重试次数。
是否有副作用。
是否需要审批。
失败返回格式。
工具一定要少。
Agent 新手最容易犯的错是给 AI 太多工具，好像给它开后宫。结果不是强，是乱。
Step 4：设置 Guardrails
最少要有：
最大步骤数。
最大运行时间。
最大 token 成本。
最大工具调用次数。
禁止访问的域名。
禁止执行的命令。
禁止输出的敏感内容。
禁止无来源结论。
禁止直接执行高风险动作。
凡是不可逆的动作，都不要让 Agent 直接做。
发送邮件、退款、删除数据、修改权限、发布内容、生产数据库写入，这些都要审批。
Step 5：做 Verification
这是灵魂。
按场景写验证器：
内容类：
检查字数。
检查格式。
检查禁词。
检查标题长度。
检查引用是否来自原文。
检查链接是否有效。
代码类：
跑 test。
跑 lint。
跑 typecheck。
跑 build。
检查 patch 是否能应用。
检查是否改了禁止文件。
数据类：
检查字段存在。
检查 SQL 运行成功。
检查数字能对账。
检查异常阈值。
检查时间范围。
网页类：
检查 URL 可访问。
检查页面状态码。
检查截图存在。
检查 diff 不为空。
检查日期合理。
客服类：
检查是否引用原对话。
检查是否命中知识库。
检查是否触发敏感升级。
检查有没有违规承诺。
Step 6：做 Failure Handler
不要让失败只显示“出错了”。
你要定义：
格式错了，重新生成一次。
链接失效，重新抓取。
网页打不开，换备用源。
缺少引用，拒绝输出。
超出步数，停止并报告。
工具失败，记录原因。
连续失败 3 次，交给人。
高风险动作，暂停审批。
模型输出不可信，降级为人工 review。
产品的成熟度，往往就藏在失败处理里。
Step 7：加 Observability
你必须记录：
用户输入。
系统上下文。
模型输出。
工具调用。
工具参数。
工具结果。
每一步耗时。
token 成本。
失败原因。
验证结果。
人工审批结果。
不要怕麻烦。
没有 trace，你永远不知道 Agent 为什么坏。
不知道为什么坏，你就没法把失败变成护城河。
Step 8：做 Eval Set
准备 50 到 100 个真实 case。
每次改 prompt、换模型、加工具、改验证器，都跑一遍。
指标至少包括：
任务成功率。
格式合格率。
引用正确率。
工具选择正确率。
平均成本。
平均耗时。
重试次数。
人工介入率。
高风险漏报率。
用户接受率。
LangSmith 文档也把 agent evaluation 分为 final response、single step、trajectory，trajectory 就是看 Agent 是否按预期路径和工具调用完成任务。(LangChain 文档)
这个对你特别有用。
因为你的产品迭代，不应该靠感觉，而应该靠：
版本 A 成功率 72%，版本 B 成功率 81%，成本下降 23%。
这才像一个能赚钱的系统。
Checklist：上线前检查清单
任务是否足够窄？
用户是否真的愿意为这个任务付费？
成功标准是否能被机器判断？
失败标准是否写清楚？
Agent 能用的工具是否被白名单限制？
每个工具是否有输入 schema？
每个工具是否有输出 schema？
每个工具是否标记了是否有副作用？
是否设置最大步骤数？
是否设置最大运行时间？
是否设置最大 token 成本？
是否设置最大重试次数？
是否有验证器？
是否不是让 AI 自己判断自己成功？
是否记录每一步 trace？
是否能看到工具调用参数？
是否能复盘失败原因？
是否有人工审批机制？
是否有权限最小化？
是否有敏感信息脱敏？
是否能从中断恢复？
是否避免重复执行副作用动作？
是否准备了 50 个真实测试 case？
是否有回归测试？
是否能对比不同模型成本和成功率？
是否能解释每个输出的依据？
是否知道失败一次的业务代价？
是否知道成功一次给用户创造多少价值？
Do List
做这些：
先写验证器，再写 prompt。
先做窄任务，再做复杂任务。
先限制工具，再开放能力。
先让 AI 生成草稿，再让系统验证。
先做只读任务，再做写入任务。
先做人类审批，再逐步自动化。
先记录失败，再优化成功。
先跑真实 case，再谈上线。
先卖给一个小众高痛点人群。
先证明省钱、省时、降风险，再谈智能。
特别重要：
每次 Agent 失败，都不要骂模型。先问 Harness 少了哪一层。
Don’t List
别做这些：
不要做万能 Agent。
不要只靠长 prompt。
不要给 Agent 无限工具。
不要给 Agent 无限权限。
不要让 Agent 自己说成功就算成功。
不要让 Agent 直接做不可逆动作。
不要没有日志。
不要没有测试集。
不要没有成本上限。
不要没有失败兜底。
不要一上来就接生产数据库写权限。
不要把 demo 当产品。
不要以为模型升级能解决所有可靠性问题。
不要追每个新框架。
不要做用户不愿付费的炫技系统。
7 天落地 To-do List
Day 1：选一个窄任务
写一句话：
我的 Agent 帮谁，在什么场景下，完成什么可验证任务。
推荐你优先选一个：
竞品监控。
客服质检。
内容再创作。
PR review。
运营异常检测。
销售线索整理。
不要超过一个。
你现在最怕的不是选择错，是同时想做十个，最后一个都不成。
Day 2：写成功标准
写 10 条机器能判断的规则。
例如竞品监控：
必须抓取指定 URL。
必须保存截图。
必须和昨日版本 diff。
必须列出变化字段。
必须带来源链接。
必须输出 JSON。
必须标明变化重要性。
无变化时必须输出 no_change。
链接不可访问时必须标记 failure。
不能编造页面不存在的信息。
Day 3：列工具
只给 4 到 6 个工具。
比如：
fetch_page
screenshot
diff_text
extract_structured_data
validate_sources
generate_report
别一开始就接 30 个工具。
你不是在培养神仙，你是在管理一个会犯错的执行器。
Day 4：写验证器
先用最笨的方法：
正则。
JSON schema。
URL status code。
字符串匹配。
字数检查。
来源检查。
截图存在检查。
diff 非空检查。
笨规则先跑起来。
不要一上来就搞复杂 LLM judge。
Day 5：写失败处理
至少写清楚：
网页打不开怎么办。
工具超时怎么办。
输出格式错怎么办。
没有来源怎么办。
验证不通过怎么办。
连续失败怎么办。
什么时候交给人。
你会发现，一旦你写失败处理，产品立刻从玩具变成系统。
Day 6：跑 50 个真实样本
不要用你幻想的样本。
用真实网页、真实客服对话、真实 PR、真实内容、真实报表。
记录：
成功率。
失败原因。
平均成本。
平均耗时。
哪一步最常失败。
用户是否觉得结果可信。
Day 7：找 5 个真实用户试用
不要问他们“你觉得这个 AI 厉害吗”。
问：
它有没有帮你省时间？
你敢不敢直接用它的结果？
哪里最不可信？
它出错一次的代价是什么？
你愿意每月为它付多少钱？
能收费，才算产品。
不能收费，就是你跟模型在谈恋爱。
你应该马上练的一个模板
每次你有 AI 产品想法，就填这个：
产品名：
目标用户：
高频痛点：
输入：
输出：
允许工具：
禁止动作：
成功标准：
验证方式：
失败处理：
人工审批场景：
日志字段：
测试样本数量：
收费理由：
例子：
产品名：竞品价格监控 Agent
目标用户：SaaS 创始人、增长负责人
高频痛点：不知道竞品什么时候改价格、加功能、改定位
输入：竞品 URL 列表
输出：每日变化摘要 + 来源链接 + 截图 + 重要性评分
允许工具：
fetch_page
take_screenshot
diff_page
extract_pricing
generate_report
禁止动作：
不能登录用户账号
不能提交表单
不能发送外部消息
不能编造未抓到的信息
成功标准：
所有结论必须有来源 URL
页面变化必须来自 diff
截图必须存在
输出必须符合 JSON schema
无变化必须明确输出 no_change
验证方式：
URL 状态码 200
diff 非空才允许报告变化
字段完整性检查
来源链接检查
截图文件检查
失败处理：
网页打不开重试 2 次
仍失败则标记 source_failed
不能生成确定结论时输出 unknown
不允许用猜测补全
人工审批场景：
周报发送给客户前需要人类确认
日志字段：
URL
抓取时间
状态码
diff
模型输出
验证结果
成本
耗时
测试样本数量：
先跑 50 个竞品页面
收费理由：
帮用户提前发现竞品价格和定位变化，节省人工监控时间
这个模板比 90% 的 AI 创业想法都更接近钱。
最后的判断
AI Harness 这件事，本质不是技术名词。
它是一个很朴素的商业真理：
你不能把不可控的东西卖给严肃客户。
你只能把被约束、被验证、可复盘、可恢复的智能卖给客户。
所以你要记住：
普通人做 AI 产品，是写 prompt。
聪明人做 AI 产品，是接工具。
高手做 AI 产品，是做 Harness。
真正赚钱的人，是做可验证的业务闭环。
你现在最该做的不是学更多概念，而是拿一个具体场景，今天就写出：
输入、工具、限制、验证、失败处理、收费理由。
这六个写不出来，就别写代码。
这六个写出来了，哪怕你不懂代码，也已经站在很多开发者前面了。
TL;DR
这期讲的是：别再迷信提示词了，真正让 AI Agent 能进生产环境的，是 Agent 外面那层 Harness，也就是控制、验证、兜底、限制、记录、重试的工程系统。
你可以把 AI 模型想成一个聪明但会撒谎、会忘事、会乱试的实习生。Harness 就是你给这个实习生配的工位、权限、工具箱、SOP、验收表、监控和主管审批。
没有 Harness，Agent 说自己完成了，但可能根本没完成。
有 Harness，它不能光嘴硬，必须被程序验证。
这场内容确实是 AI Engineer Europe 2026 议程里的演讲，题目是 Harnesses in AI: A Deep Dive，演讲者是 IBM 的 Tejas Kumar。(ai.engineer) Podwise 的摘要也说，这个主题核心是用 tool registry、step limit、verification loop 等结构，把黑箱、不稳定的 AI 模型包进一个稳定、可控的环境里。(Podwise)
这东西到底是什么
AI Harness，中文可以粗暴理解成 AI 安全带、AI 操控台、AI 运行框架。
它不是模型本身。
它也不是提示词。
它是模型外面那一圈工程控制层。
比如一个 Agent 要帮你自动完成某个任务：
它可以查数据库，调用浏览器，写文件，发邮件，调用 API，修改代码。
问题是，AI 天生不是确定性的。它可能今天对，明天错；第一次成功，第二次卡住；明明没登录，却说已经完成；明明没发出去，却说已经发了。
Harness 要解决的就是这件事：
不相信 AI 自己说成功。
只相信系统验证过的结果。
这就是这期最重要的一句话。
它包含什么
一个完整的 Agent Harness 通常包括这些东西：
Frank’s World 对这场演讲的总结里也列到了 tool registry、model management、context management、guardrails、verification steps 这些组成部分。(Frank's World of Data Science & AI) daily.dev 的摘要也说，Agent Harness 是模型周围的一切，用来把模型固定在稳定、确定性的运行环境中，包括工具注册、上下文管理、最大步数、Agent loop 和 verify step。(daily.dev)
这期的现场 demo 讲了什么
Tejas Kumar 做了一个很有意思的 demo：让一个浏览器 Agent 去 Hacker News 上给帖子点赞。
没有 Harness 的时候，Agent 会遇到典型问题：
它没登录。
它不知道该怎么处理登录页。
它可能以为自己点赞成功了。
甚至它会直接幻觉式宣布任务完成。
然后他不是去疯狂改 prompt，而是加了几层 Harness：
第一，加 guardrails，限制最大步骤数，防止 Agent 无限循环。
第二，加 verify step，检查点赞是否真的成功。
第三，加登录处理逻辑，遇到登录页时用确定性的程序处理登录。
第四，让 Agent 的结果必须通过外部状态验证，而不是听它自己汇报。
BigGo 的总结里提到，这个演示用一个较弱的 GPT-3.5 Turbo 模型，通过 guardrails、verify step 和 programmatic login handler，让浏览器任务变得可靠，而不是靠修改 system prompt。(BigGo Finance) daily.dev 的摘要也提到，它增量加入了 guardrails、context compression、verify step 和 deterministic login handler。(daily.dev)
这背后的狠话是：
模型弱一点没关系，工程系统强，照样能做事。
模型再强，外面没有 Harness，也只是一个会表演的黑箱。
它和 Prompt Engineering 的区别
你现在要把这个区别刻进脑子里。
Prompt Engineering 是对 AI 说：你要认真。
Harness Engineering 是对 AI 说：你只能用这些工具，最多走 10 步，每一步我都记录，最后我用程序检查你到底成没成功，失败就重试或交给人。
这两个完全不是一个层级。
提示词像口头交代。
Harness 像公司制度。
提示词问的是：我怎么让 AI 更听话？
Harness 问的是：就算 AI 不听话，我怎么让系统仍然可靠？
这就是生产级 AI 产品的分水岭。
为什么这对你特别重要
你如果是独立开发者，想靠 AI 产品赚钱，不要一上来就做什么万能 Agent。那是平庸之辈最容易掉进去的坑，看起来宏大，实际上不可控、不可卖、不可复现。
你要做的是：
找一个窄任务，做一个可靠 Agent。
比如：
帮 Shopify 店主每天检查差评并生成回复。
帮律师助理整理合同风险点，但必须引用原文。
帮 SaaS 创业者监控竞品更新并生成周报。
帮 YouTuber 把视频转成小红书、推特、Newsletter，但必须符合格式检查。
帮小公司自动处理客服，但退款、法律、医疗类问题必须升级给人。
这些任务赚钱的关键不是 AI 多聪明，而是：
它能不能稳定完成？
它能不能少出错？
它错了能不能被发现？
客户能不能信任它？
这就是 Harness 的商业价值。
你可以怎么学以致用
你不要学这个概念本身。概念不值钱。
你要学的是这个思想：
任何 AI 产品，都必须从 prompt 变成 process。
也就是从一句话命令，变成一套可执行流程。
比如你要做一个 AI 竞品监控工具，错误做法是：
让 AI 去网上看看竞品最近有什么变化，然后总结。
这就是小孩过家家。
正确做法是：
先限定它只能访问哪些网站。
再规定它每天抓哪些页面。
再把抓到的页面和昨天版本做 diff。
再让 AI 只解释 diff。
再要求每个结论必须带来源链接。
再用验证器检查链接是否存在、日期是否合理、输出是否符合 JSON 格式。
最后记录日志，失败就重试，连续失败就通知你。
这才叫产品。
一个最小 Harness 长什么样
伪代码大概是这样：
输入任务
↓
加载允许使用的工具
↓
加载上下文和历史状态
↓
开始 Agent Loop
↓
模型决定下一步动作
↓
系统检查这个动作是否被允许
↓
执行工具
↓
记录结果
↓
更新上下文
↓
检查是否达到最大步数/最大成本
↓
验证任务是否真的完成
↓
成功：输出结果
失败：重试/调用兜底逻辑/交给人
这里最关键的是最后那个验证。
不要问 AI：你完成了吗？
要问系统：外部状态证明它完成了吗？
比如：
生成文章，要检查字数、格式、禁词、链接、标题长度。
改代码，要跑测试、lint、typecheck。
发邮件，要检查邮件是否进入 sent 状态。
爬网页，要检查 URL、时间、正文是否真的存在。
处理订单，要检查数据库状态是否更新。
客服回答，要检查答案是否引用了知识库内容。
你现在最应该做的一个练习
选一个你正在想做的 AI 产品，然后不要写 prompt，先写这 9 个东西：
用户给我的输入是什么？
Agent 最终要产出什么？
什么叫成功？
什么叫失败？
它允许调用哪些工具？
它绝对不能做什么？
我怎么用程序验证它真的成功？
如果失败，它重试几次？
哪些情况必须交给人？
你把这 9 个写清楚，你就已经比 80% 的所谓 AI 创业者强了。因为大部分人还停留在：我写了个很长的 prompt。
长 prompt 不叫产品。
可验证流程才叫产品。
SOP：把一个普通 AI 功能改造成 Harness 产品
Step 1：选择窄任务
不要做万能助手。
选一个具体、高频、有钱味、可验证的任务。
好任务：
客服分类
合同摘要
竞品监控
邮件回复草稿
代码 PR 检查
广告文案生成
财务报表异常检测
短视频脚本批量生成
坏任务：
帮我经营公司
帮我自动创业
帮我成为世界首富
全自动 CEO Agent
越大越废，越窄越值钱。
Step 2：定义成功标准
写成机器能判断的标准。
不要写：
输出一篇不错的文章。
要写：
标题少于 30 个中文字符。
正文 800 到 1200 字。
必须包含 3 个小标题。
必须包含 CTA。
不能出现违禁词。
必须返回 JSON。
每个事实必须带来源链接。
你看，这就开始像工程了。
Step 3：建立 Tool Registry
列出 Agent 能用的工具。
例如：
搜索工具
网页抓取工具
数据库查询工具
邮件发送工具
CRM 查询工具
文件读取工具
代码执行工具
支付查询工具
每个工具必须有：
输入格式
输出格式
权限限制
失败返回
超时时间
成本上限
别让 Agent 像喝醉的猴子一样到处乱点。
Step 4：加 Guardrails
最低限度要有这些限制：
最大步骤数
最大 token 成本
最大运行时间
最大重试次数
允许访问的域名
禁止执行的动作
高风险操作必须人工确认
输出必须是结构化格式
特别是发邮件、转账、退款、删库、改用户数据这种动作，必须有人类审批。
Step 5：加 Verify Step
这是灵魂。
不同产品有不同验证器：
内容产品：检查格式、字数、禁词、链接、SEO 字段。
代码产品：跑测试、lint、typecheck、构建。
客服产品：检查是否引用知识库、是否触发敏感升级。
爬虫产品：检查页面是否真实抓到、日期是否匹配。
销售产品：检查邮箱是否有效、公司是否真实、职位是否匹配。
数据分析产品：检查 SQL 是否成功、字段是否存在、数字是否对得上。
记住：验证器越强，模型越可以便宜。
Step 6：加 Failure Handler
不要让失败变成沉默。
你要定义：
登录失败怎么办？
API 失败怎么办？
网页打不开怎么办？
信息缺失怎么办？
模型输出格式错怎么办？
验证不通过怎么办？
连续失败三次怎么办？
这一步是你从玩具走向产品的关键。
Step 7：做 Eval Harness
准备 30 到 100 个测试案例。
每次改 prompt、换模型、加工具，都重新跑一遍。
记录：
成功率
平均成本
平均耗时
失败原因
人工介入比例
用户满意度
幻觉率
格式错误率
这就是你真正的护城河。不是你用了哪个模型，而是你积累了多少真实任务的失败样本和修复逻辑。
Checklist：上线前检查清单
任务是否足够窄？
成功标准是否能被程序判断？
Agent 能用的工具是否被白名单限制？
每个工具是否有输入输出 schema？
是否设置最大步骤数？
是否设置最大成本？
是否设置最大运行时间？
是否有 verify step？
是否不是靠 AI 自己说成功？
是否有失败重试？
是否有失败升级给人的机制？
是否记录每一步日志？
是否能复盘失败原因？
是否有测试集？
是否能切换模型？
是否避免供应商锁死？
是否把高风险动作交给人审批？
是否能解释每个输出来自哪里？
是否能给用户一个可信结果，而不是一段漂亮废话？
Do List
做这些：
先设计验证器，再设计 prompt。
先做窄场景，再做复杂场景。
先限制工具，再开放能力。
先记录失败，再优化体验。
先跑 50 个真实 case，再谈上线。
把 Agent 每一步都日志化。
输出尽量结构化，比如 JSON。
高风险操作必须人工确认。
每次失败都变成一条新规则。
能用便宜模型解决，就别迷信最贵模型。
Don’t List
别做这些：
不要一上来做万能 Agent。
不要以为 prompt 长就可靠。
不要让 AI 自己判断自己是否成功。
不要无限循环。
不要给 Agent 无限浏览、无限工具、无限权限。
不要让 Agent 直接执行不可逆操作。
不要没有日志。
不要没有测试集。
不要每次失败都只说换更强模型。
不要把 demo 当产品。
7 天落地 To-do List
第 1 天：选任务
选一个你愿意做成产品的窄任务。
建议优先选：
AI 竞品监控
AI 客服质检
AI 内容格式化
AI 广告文案生成
AI 代码审查
AI 邮件回复草稿
写出一句话：
我的 Agent 帮谁，在什么场景下，完成什么可验证任务。
第 2 天：写成功标准
写 10 条机器可判断规则。
比如：
必须输出 JSON。
必须包含来源链接。
不能超过 500 字。
必须引用原始文档。
必须给出 confidence score。
必须标记不确定信息。
必须通过格式校验。
第 3 天：列工具
列出 Agent 能用的工具。
比如：
search_web
fetch_url
read_file
write_file
query_database
send_email_draft
run_test
check_format
每个工具只做一件事。
第 4 天：做验证器
不用高级。
先用最笨的方法：
正则检查
JSON schema 检查
关键词检查
链接可访问检查
字数检查
测试命令检查
数据库状态检查
笨验证器比聪明幻觉可靠。
第 5 天：做失败处理
写清楚：
格式错，重新生成。
链接失效，重新抓取。
缺少引用，拒绝输出。
超出步数，停止并报告。
高风险动作，交给人确认。
三次失败，输出失败原因。
第 6 天：跑 50 个案例
不要自己幻想。
找 50 个真实输入跑。
记录：
成功几个
失败几个
哪里失败
平均多少钱
平均多久
用户是否能接受
第 7 天：给 5 个真实用户试用
不要憋大招。
找 5 个人用。
你只问三个问题：
这东西有没有替你省时间？
哪里不可信？
你愿不愿意每月付 10、30、99 美元？
如果没人愿意付费，别美化它。修任务，修场景，修价值。
最后给你一句狠的
这期真正讲的不是 AI Harness。
它讲的是一个残酷事实：
AI 创业的胜负，不在谁会调戏模型，而在谁能把不稳定的智能，压进稳定的流程。
普通人追模型。
高手做系统。
赚钱的人做可验证的系统。
你要学以致用，就从今天开始，把你每一个 AI 想法都改写成这句话：
输入是什么，工具是什么，限制是什么，怎么验证成功，失败怎么兜底。
这就是 Harness 思维。