Anthropic just shipped 10 pre-built agent templates for financial services. Pitch decks. Earnings reviews. Financial models. Valuations. Ledger reconciliation. Month-end close. Audit prep. KYC screening. Each one is a packaged stack — skills, connectors, sub-agents — that drops into Claude Code, Claude Cowork, or Managed Agents. The pattern is locked in: Prompts are conversation. Skills are infrastructure. Vertical agent bundles are the next SaaS layer.
AI Agent 真正难的不是模型，是那层「外壳」
2026 年 5 月最值得 PM 看懂的技术趋势：让 Agent 从玩具变工具的关键不是模型本身，而是围绕模型的工程包裹层（Harness）。ArXiv 最新实证 + Anthropic 金融 Agent 模板热潮，把这件事变成了可操作的产品决策指南。
リサーチノート
「模型再强，没有外壳也跑不起来。」
这句话在 2026 年 5 月终于从工程师的私下共识，变成了可以拿数据来背书的结论。
真正的突破不是模型，是包裹模型的那层东西
过去两年，AI 新闻的焦点一直是模型——哪个 benchmark 刷新了，哪家发布了多少参数，哪个模型便宜又准。但在研究者眼里，让 Agent 真正能用的那个东西有个专门的名字：Harness（哈内斯），即围绕大模型的工程包裹层。
它管什么？管工具怎么调用、上下文怎么存取、任务怎么编排、执行边界怎么控制、安全机制怎么嵌入。一句话：模型是大脑，Harness 是身体加神经系统。
2026 年 4 月，来自香港大学的研究者 Hu Wei 对 70 个公开 Agent 系统项目做了迄今为止最系统的 Harness 架构实证研究，结论写得很直白1：
AI agent systems increasingly rely on reusable non-LLM engineering infrastructure — tool mediation, context handling, delegation, safety control, and orchestration. Yet the architectural design decisions in this surrounding infrastructure remain understudied.
翻过来说：大家都在研究模型，没人系统研究外壳。但这个外壳，才是决定 Agent 能不能落地的关键。
「外壳」里有什么？五个维度，决定 Agent 是玩具还是工具
研究者用五个维度给所有 Agent 项目画像1：
| 维度 | 问的问题 | 典型差异 |
|---|---|---|
| 子 Agent 架构 | 能不能拆分任务、协调多个 Agent？ | 30% 项目仅支持单 Agent，19% 已支持主从编排 |
| 上下文管理 | 上次做了什么、记住多少？ | 从会话级内存到企业级向量数据库，层次悬殊 |
| 工具系统 | 能接多少外部能力，怎么注册？ | 34% 用显式注册表，14% 已走 MCP 协议 |
| 安全机制 | 执行有没有边界，操作有没有审计？ | 只有 5% 实现了防篡改审计链 |
| 编排逻辑 | 任务怎么拆解、步骤怎么排列？ | 50% 仍是 ReAct 式单循环，35% 已走「先计划再执行」 |
一个让 PM 反直觉的发现：编程语言和用途标签对架构复杂度的预测力接近于零。同样是「代码助手」，有的只是薄薄的 API 封装，有的已经是带容器隔离、策略审计、多层编排的生产级平台。判断一个 Agent 产品成不成熟，看这五个维度比看它是「基于 GPT 还是 Claude」靠谱得多。
为什么现在这件事突然被说明白了？
一个事件链把这个抽象概念变成了真实新闻。
Anthropic 在 5 月初发布了 10 个面向金融服务的现成 Agent 模板——覆盖 Pitch 制作、估值审查、月末结账、KYC 合规筛查等3。每个模板都是打包好的「技能 + 连接器 + 子 Agent」组合，可以直接装进 Claude Code、Cowork 或作为 Managed Agent 部署。这个发布在 X 上收获了 2 万点赞，是同期 AI 新闻里互动最高的条目之一。
コンテンツカードを読み込んでいます…
同一周，OpenAI 发布了带开源 Harness 的 TypeScript Agents SDK4，允许开发者接入沙盒 Agent 和标准化工具层。
这两个发布的共同信号是：模型公司已经不再只卖「会思考的大脑」，开始打包交付「能干活的身体」。对 PM 来说，意思很具体——如果你的竞品用了打包好的金融 Agent 模板而你还在手动搭提示词，你们用的实际上不是同一代产品。
从「能用模型」到「能用 Agent」，差的是什么？
同期另一篇 ArXiv 论文用一个问题把整件事说得很清楚。论文标题叫《The Last Harness You'll Ever Build》（你最后要搭的那个外壳），核心观点是：每次进入新业务领域，你都要重新设计一套 Harness——提示词、工具逻辑、编排规则、评估标准，这是目前 Agent 落地最贵的部分，不是模型 API 的调用费5。
リンクプレビューを読み込んでいます…
他们的解法是两层循环：让 Agent 在执行任务的过程中自动迭代自己的 Harness，再让另一层「元循环」学会快速为任何新任务收敛出合适的 Harness——理想状态下，适配一个新业务领域不再需要人工工程。
这个方向还在研究阶段，但它清楚描绘了现在的成本结构：Harness 工程是瓶颈，不是模型能力。
PM 能用这些做什么？三个具体判断
一、评估供应商时，加一套 Harness 问卷
光问「用的什么模型」已经不够。可以追问：上下文怎么管理、支持哪些工具注册协议、执行有没有容器隔离、有没有操作审计日志。这五个维度（架构/上下文/工具/安全/编排）对应了实际部署能力，比「支持哪些语言」更能反映可用性。
二、优先选「垂直 Harness 模板」，而不是通用 Agent API
Anthropic 的金融服务模板说明了一件事：同样的模型，配上行业专属的工具列表、预设连接器和业务编排逻辑，落地速度相差可以是 10 倍。如果你做的是有明确业务流程的产品（报销、合规、客服、研报），先找有没有现成的垂直 Harness，而不是从零搭 Agent。
三、自建时，把「工程层」的设计提前
如果确定要自建 Agent 产品，现在最常见的陷阱不是模型选错，而是「工程层设计太晚」——先集成 API，发现跑不稳了才开始想上下文怎么管、工具怎么隔离。70 个项目的实证研究结论是：深度协调（多子 Agent）、持久化上下文、结构化安全机制这三件事，几乎总是绑在一起出现的。任何一个做晚了，另两个都要补做一遍。
一句话总结给下次跟技术团队开会用：Agent 落地的主要成本在 Harness 工程，不在模型调用。问供应商「Harness 怎么建的」比问「用什么模型」更有决策价值。
このコンテンツについて、さらに観点や背景を補足しましょう。