Anthropic MHS标准解读：重塑Agent工具调用与上下文管理

近几个月，AI 领域的竞争已经从前端模型能力，悄悄转移到了更底层的地方：上下文怎么组织、工具怎么调用、模型与外部系统之间怎么约定交互格式。

如果你一直在用 Claude 的 API，或者正在做 Agent 类应用，大概率会遇到一个非常直接的痛点：各家模型有各自的 tool calling 格式，各家 Agent 框架有各自的消息封装方式，换一个模型厂商，就要改一遍协议适配代码。这个成本在单模型时代不明显，但到了多模型、多工具、多智能体协作的阶段，会直接拖垮迭代速度。

Anthropic 最近放出的 MHS 标准研究预览，正是冲着这个问题去的。这篇文章不打算只复述官方公告，而是想从开发者的实际视角拆开来看：MHS 到底解决什么问题，它和已有方案是什么关系，你现在能做什么，以及最重要的——它值不值得你关注。先给一个明确判断：MHS 的意义不在“又多了一个标准”，而在它试图把模型与工具之间那层“隐式的、各写各的”约定，变成“显式的、可校验的”机器可读规范。这一变化如果落地，Agent 开发方式会被重塑。

1. 这篇文章真正要解决的问题

先说一个比较扎心的现状：现在的 Agent 开发，看起来是在写业务逻辑，实际大量时间花在了“格式翻译”上。

比如你要让模型调用一个函数，OpenAI 的格式是一套 JSON Schema 风格，Anthropic 的格式里带了input_schema之类的字段，别的厂商又有自己的parameters写法。就算大家都说“兼容 OpenAI”，真正接入后你会发现，工具描述里的细节、流式事件里tool_use和tool_call的命名、错误返回里的字段层级，全都不一样。

这种情况带来的直接后果有三个：

1. 模型切换成本高：今天用 Claude，明天想换别的模型，或者做模型路由，工具定义层基本要重写。
2. 工具复用难：你给 A 模型写好的工具描述，B 模型读不懂，跨系统共享工具更是无从谈起。
3. 调试链路长：报错到底是模型没按格式返回，还是我的工具定义不符合模型预期？排查起来经常要靠人工比对文档。

MHS 这个标准研究预览，想做的就是把这一层统一起来。从材料看，它更像是一个“研究预览”，而不是马上要强制所有人迁移的正式标准。这句话的信息量很大：它意味着技术方向已经明朗，但细节还在打磨；意味着你现在可以了解它、试用它，但不至于马上被兼容性绑架。

所以这篇文章会从几个层面展开：先讲清楚 MHS 要解决的协议碎片化问题，再和现有方案做对比，然后给出一个你能实际体会的示例思路，最后聊聊这个标准如果落地，对普通开发者的工程影响是什么。

2. MHS 的基础概念与核心设计思路

2.1 MHS 到底是什么

MHS 这个名称，从 Anthropic 的技术语境和搜索材料来看，合理推断是Model Handling Specification或Model Context Specification的缩写，中文可以理解为“模型交互规范”或“模型上下文规范”。它要定义的是：当模型需要调用外部工具、读取外部资源、或者与另一个模型协作时，双方应该用什么结构来表达请求、传递上下文、接收结果。

拆开看，包含这么几层：

• 工具描述的标准化：模型的工具调用格式不再是各家自定义，而是有了统一的结构，包括工具名称、参数定义、返回值类型、错误语义。
• 上下文传输的标准化：多轮对话中，哪些上下文需要传给模型、哪些可以省略、工具的返回结果如何折叠进对话历史，这些策略被固化成了规范。
• 交互协议的标准化：模型和宿主应用之间，用什么样的消息流来表达“我需要调用工具”“工具执行完了”“结果可能需要再处理”。

这其实就是把过去散落在各个框架里的“潜规则”抽出来，变成一份显式文档和一套可校验的 schema。

2.2 为什么要做这件事：从 JSON 格式到“语义契约”

如果你写过 Web 后端，会发现 MHS 想做的事情和 OpenAPI 非常像。

早期前后端联调，大家口头约定接口字段，前端写一个{ name: 'tom', age: 18 }，后端根据文档解析。接口多了以后，文档经常过期，字段经常对不上。于是有人做了 OpenAPI（Swagger），把接口契约写成机器可读的 YAML/JSON，前端可以生成类型、后端可以生成 mock、测试可以校验 schema。

MHS 就是这个思路在 AI 交互层的复刻。工具调用不再是“你按我的格式来”，而是“我们用同一份合同”。模型的工具定义是一份合同，宿主应用的执行结果是一份合同，模型与模型之间的消息传递也是一份合同。有了合同，就能做校验、做缓存、做可观测性，甚至做跨厂商的迁移。

这个比喻可能更好理解：过去你请不同国家的承包商干活，每个人用自己的一套图纸符号，你得分别翻译；MHS 就是想统一这套图纸符号，让大家都能看懂、能相互检查。

2.3 关于可解释性的联想

热搜词里出现了“anthropic 可解释”。这提醒我们：MHS 这样的标准不仅影响工程效率，还间接影响模型行为可解释性。

当模型调用工具时，如果交互格式是隐式的、临时拼装的，你很难追踪模型每一步的决策依据。工具返回了什么东西、模型基于什么上下文做了下一步判断，这些过程全是黑盒。而标准化的格式天然带有结构化字段，比如request_id、tool_call_id、context_digest之类，一旦这些字段成为规范的一部分，调试和审计就会容易得多。

所以 MHS 不只是工程规范的进步，它也提供了一条通向“可解释、可审计 Agent”的路径。开发和运维视角下，这个价值甚至比少写几百行适配代码更重要。

3. 对比现有方案：MHS 和 Function Calling、MCP 之间的边界

很多读者会有一个疑惑：Function Calling（函数调用）和 MCP（Model Context Protocol）不是已经在做类似的事吗？MHS 和它们是什么关系？

这里必须先做一个清晰的区分。

3.1 Function Calling：模型侧的接口约定

Function Calling 本质上是模型的一种能力。你给模型提供工具描述，模型在合适的时候返回一个“我想调用这个工具”的结构化结果。它是模型输出层的约定。问题是，这个约定由每家模型厂商各自定义，OpenAI 有functions，Anthropic 有tools，Google 有functionDeclarations。这个层面，不统一。

3.2 MCP：客户端与服务端之间的协议

MCP 是 Anthropic 之前推出的模型上下文协议，它的核心是：让 AI 应用（宿主）和外部工具/数据源（MCP Server）之间通过一个标准协议通信。这个协议标准化的是“宿主 ↔ 工具”这一段。

MCP 解决了一个问题：我不需要为每个数据源单独写适配器，只要数据源提供一个 MCP Server，应用就能连上。但它没有解决另一个问题：模型返回的 tool_use 格式，仍然是模型厂商定义的。MCP 的 Server 能收到工具请求，但对“这个请求是怎么被模型产生的”这件事，MCP 并不关心。

3.3 MHS：交互语义层的统一

MHS 更偏向模型与宿主之间的“会话层”标准，它要定义的是模型怎么表达“我要调用工具”、宿主怎么返回结果、上下文怎么裁剪、错误怎么处理。它处在 Function Calling 之上、MCP 之下，是连接两者的缓冲层。

可以用一个表格来对比：

3.4 对开发者的实际含义

如果你只接触其中一个，很容易觉得“够了”。但真实的 Agent 架构里，三层是同时存在的：

模型（输出层） —— MHS（交互层） —— 宿主应用 —— MCP（工具通信层） —— 工具服务

MHS 的野心，是把“模型输出格式”和“宿主如何处理”之间的语义打平。这样同一份工具定义，Claude 能用，换一个同样遵循 MHS 的模型也能用；同一份交互日志，A 框架解析没问题，B 框架也都能读懂。

这就引出一个关键判断：未来写 Agent，可能不再是给某一家模型写工具，而是给整个遵循标准的多模型生态写工具。这个变化对架构设计的影响是根本性的。

4. 前沿探索：从模型交互到“上下文编排”

既然 MHS 标准本身还是研究预览，很多实现细节还在演进，但我们可以从标准想解决的问题反推出它对 Agent 架构的深层影响。

4.1 上下文不再是“搬运”，而是“编排”

目前大部分 Agent 框架处理上下文的方式很粗暴：把所有历史消息一股脑塞给模型。工具调用很多轮之后，token 消耗巨大，而且模型真正需要的，往往只是最后一次工具结果和用户当前意图。

MHS 如果想把上下文传输标准化，就不可能允许“无脑塞全部”。它一定会推动一种新的上下文处理方式：对历史消息做结构化压缩，对工具结果做摘要化折叠，对重要信息做优先级标记。

这意味着 Agent 框架的核心能力，将从“把消息串起来”变成“判断哪些上下文值得保留”。这更接近人类协作时的信息管理方式：不是把所有聊天记录都翻出来，而是把关键结论、当前状态、下一步动作整理清楚。

4.2 工具描述走向“组件化”和“可复用”

有了统一的工具描述规范，工具的复用方式会发生变化。今天你的工具函数是写在代码里的，被当前这个 Agent 调用。将来，如果工具描述能独立于具体模型存在，你可以维护一套“企业内部工具目录”，每个工具用标准 schema 描述能力、权限、参数、返回结构。

新的 Agent 项目启动时，不是从零写工具，而是从目录里“订阅”需要的工具。这个思路和微服务里的 API 网关很像：服务能力统一注册，调用方按需接入。

4.3 更安全的工具调用边界

从安全角度看，标准化的交互层还带来了一个重要收益：边界检查更清晰。

没有标准时，工具调用是“模型说调就调”，宿主很难在统一位置做权限校验。有了标准交互层，工具调用请求会经过一个统一的、可校验的入口，这意味着权限控制、敏感操作确认、审计日志都能在这个入口集中完成。

这对于企业级应用尤其重要。想想一个场景：Agent 在对话中自然地说“我帮你删掉这个测试环境”，虽然模型本意是好的，但工具调用前是否应该有人类确认？在非标准化的交互层，这个确认逻辑需要自己写；在标准化层，这可以是规范规定的一个强制节点。

5. 如何跟进和尝试 MHS：概念验证与模拟示例

MHS 还在研究预览阶段，官方 API 可能还没有完整开放给所有开发者。但你不必干等。下面给出一个思路：用当前已经可用的工具，模拟“基于统一工具定义”的开发方式，为将来迁移到 MHS 做好准备。

5.1 给工具定义一份“中立层”

这一步的核心思路是：不让业务代码直接依赖模型厂商的 tool 格式，而是先定义一份中立的工具描述结构。

我们可以用一个 JSON Schema 风格的中间格式来定义工具，这个结构先不管 Anthropic 还是 OpenAI，只描述“这个工具做什么、需要什么参数、返回什么”。

以一个天气查询工具为例，中立的工具描述文件可以长这样：

{ "tool_id": "weather_query_001", "name": "query_weather", "description": "根据城市名查询当前天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如 北京、上海" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius" } }, "required": ["city"] }, "returns": { "type": "object", "properties": { "temperature": { "type": "number" }, "humidity": { "type": "number" }, "condition": { "type": "string" } } } }

这份文件不隶属于任何厂商。它就是你的“MHS 雏形”——描述工具的契约。

5.2 写一个适配函数：从通用描述生成厂商格式

接下来，写一个适配器，把这份中立描述转换成当前模型需要的格式。

# 文件路径：adapters/tool_adapter.py def to_anthropic_tool(tool_spec: dict) -> dict: """将中立工具定义转换为 Anthropic 工具格式""" return { "name": tool_spec["name"], "description": tool_spec["description"], "input_schema": tool_spec["parameters"] } def to_openai_tool(tool_spec: dict) -> dict: """将中立工具定义转换为 OpenAI 工具格式""" return { "type": "function", "function": { "name": tool_spec["name"], "description": tool_spec["description"], "parameters": tool_spec["parameters"] } }

有了这两个函数，你的业务代码只关心中立描述，厂商差异被隔离在适配层。将来 MHS 正式可用，只需要新增一个to_mhs_tool适配函数。

5.3 执行函数：用一个统一入口处理工具调用

然后，写一个统一的工具执行入口，它接收模型返回的工具调用结果，解析出工具名和参数，执行后返回结构化结果。

# 文件路径：executor/tool_executor.py TOOL_REGISTRY = {} def register_tool(name: str, func): TOOL_REGISTRY[name] = func def execute_tool_call(tool_call: dict) -> dict: """ tool_call 的格式假设为公司内部统一格式： { "tool_name": str, "arguments": dict } """ tool_name = tool_call.get("tool_name") arguments = tool_call.get("arguments", {}) if tool_name not in TOOL_REGISTRY: return { "status": "error", "message": f"tool {tool_name} not found" } try: result = TOOL_REGISTRY[tool_name](**arguments) return { "status": "success", "result": result } except Exception as e: return { "status": "error", "message": str(e) } def query_weather(city: str, unit: str = "celsius"): # 这里替换为真实天气服务的调用 return { "temperature": 22, "humidity": 43, "condition": "晴" } register_tool("query_weather", query_weather)

注意，这个统一入口的核心价值：无论模型怎么表达“我想调用工具”，在到达执行器之前，都会先被转换为统一格式。这正好是 MHS 想标准化的部分。

5.4 验证方式

在概念验证阶段，你可以写一个简单的测试脚本，模拟模型返回的工具调用，验证执行链路是否通畅：

# 文件路径：tests/test_tool_executor.py from executor.tool_executor import execute_tool_call test_call = { "tool_name": "query_weather", "arguments": {"city": "北京", "unit": "celsius"} } result = execute_tool_call(test_call) print(result) assert result["status"] == "success" assert "temperature" in result["result"]

运行命令：

python tests/test_tool_executor.py

预期输出：

{"status": "success", "result": {"temperature": 22, "humidity": 43, "condition": "晴"}}

这个验证通过，说明你已经具备了一套“不依赖厂商、可替换模型”的工具调用雏形。之后 MHS 的任何进展，你都可以在这个框架里平滑接入。

6. 连接异常问题排查：Anthropic API 接入的常见坑

在关注 MHS 的同时，很多开发者也反馈过 Anthropic API 连接方面的问题。网络热词里出现了类似unable to connect to anthropic services、failed to connect to api.anthropic.com这样的内容。这里专门补充一节排查思路，帮助你在接入或预研过程中少走弯路。

6.1 问题现象

典型的报错信息包括：

• unable to connect to anthropic services
• failed to connect to api.anthropic.com
• Connection error: [Errno 11001] getaddrinfo failed
• 偶发性的 529、503 状态码

6.2 排查步骤

遇到连接问题，按下面的顺序排查，效率最高：

第一步：检查网络连通性。

ping api.anthropic.com curl -I https://api.anthropic.com

如果curl能收到响应，说明基本网络是通的。如果出现超时或 DNS 解析失败，需要检查本地网络环境、代理配置和 DNS 设置。

第二步：检查 SDK 版本与端点配置。

不同版本的 Anthropic SDK 使用的 base_url 可能不同，如果你手动配置了端点，要确认没有拼写错误，没有混用官方地址和自定义网关地址。

第三步：检查认证信息和请求频率。

如果认证信息格式错误，服务端会直接拒绝连接。同时要注意，如果在短时间内发出大量请求，也可能触发限流，表现为连接被重置或返回 429/529。

6.3 错误排查速查表

这里特别提醒：任何情况下，都要确保你使用的是合法合规的网络环境，并遵守相关服务条款。如果在国内服务器直连遇到连接问题，建议优先排查项目本身的网络策略，而不是绕过网络限制。

6.4 给接入工程师的建议

在接入 Anthropic API 的项目里，连接层最好做三层保护：

1. 超时控制：连接超时和读取超时分开设置，避免无限等待。
2. 重试策略：遇到 529、503 或者连接中断时，采用指数退避重试，而不是立即重试。
3. 失败降级：如果主模型服务不可用，至少要能返回可读的错误信息，不要让用户面对一串堆栈。

7. MHS 潜在影响评估：谁受益最大

标准这种东西，最怕的就是“看起来有用，落不了地”。所以我们要冷静评估一下：如果 MHS 从预览走向正式标准，不同角色分别能得到什么。

7.1 Agent 框架开发者

受益最大。他们不需要再为兼容各家模型工具格式而写一堆判断分支。框架的核心逻辑可以集中在状态管理、上下文编排和任务调度上，协议层交给标准。

换个说法：今天框架作者最头疼的“model A 支持这个功能，model B 不支持，跑起来就崩”这类问题，会大幅减少。框架的兼容性列表会越来越长，而背后的适配代码却越来越少。

7.2 企业应用开发者

收益也很直接。企业内部往往有自己的一套工具系统、数据库、内部 API。过去要让模型调用这些工具，每次都要写适配。如果 MHS 成熟，企业只需要把自己的工具能力按照标准发布一次，后续所有支持该标准的模型都可以接入。

更重要的是，标准化的交互层为企业级审计提供了天然节点。每次工具调用都有统一的请求 ID、统一的格式、统一的上下文记录，这让安全审计和合规检查变得清晰可控。

7.3 模型开发者

同样有动力支持。模型厂商可以不必把精力浪费在“发明一套新的工具格式”上，而是专注提升模型本身的推理能力和工具选择准确率。多模型共存时，用户切换模型的成本降低，反而会促进整个市场更活跃。

7.4 普通 AI 应用用户

用户感知到的变化是：同样的助手能力，体验更稳定了。工具调用失败率降低，模型不会因为格式理解偏差而反复返回无效结果。多步骤的 Agent 任务执行更加连贯。

当然，也要泼一点冷水。标准的制定从来不等于标准的落地。MHS 要真正产生价值，还需要满足三个条件：

1. Anthropic 自己持续投入，并把标准放到开放社区讨论，而不是只服务于自家模型。
2. 其他主要模型厂商愿意采纳，至少做到“兼容不低于 MHS”。
3. 主流的 Agent 框架愿意把 MHS 作为默认交互层来集成。

这三个条件缺一个，MHS 就可能沦为“文档里的规范”，而不是“工程里的标准”。

8. 面向未来的工程实践建议

不管 MHS 最终以什么形态落地，有几条工程实践原则是现在就可以执行的，它们能让你在未来标准切换时占据主动。

8.1 构建“中立工具定义层”

这是最核心的建议。在项目中增加一层工具定义，不直接使用厂商的 schema，而是定义自己的中间结构，再通过适配器转换。

这样做的好处是：

• 模型切换时，只改适配器，不改业务代码。
• 工具描述与模型强解耦，同一套工具可以被多个模型复用。
• 未来 MHS 落地，新增一个适配器即可，成本极低。

8.2 尽早建立“可观测的交互日志体系”

Agent 应用调试最大的痛点就是黑盒。建议从第一天起，就把每条消息、每次工具调用、每轮上下文裁剪都记录成结构化日志。字段至少包括：

• 时间戳
• 会话 ID
• 模型名称
• 工具名称
• 输入摘要
• 输出摘要
• 上下文 token 数
• 耗时
• 是否命中缓存

这些数据今天用于调试，明天就是优化上下文策略的依据，后天可能是训练专业模型的语料。无论如何，都不亏。

8.3 对标准保持“关注但不过度投入”

研究预览阶段，不建议把核心业务迁移到尚未稳定的规范上。更稳妥的做法是：以概念验证的方式跟踪标准发展，但生产环境继续使用当前成熟的技术方案。等到标准发布 RC 版本、主流框架开始集成时，再逐步迁移。

这一点很关键，因为过早绑定一个未定稿的标准，可能会让你在标准迭代过程中反复返工。

8.4 关注上下文管理能力

MHS 如果成立，Agent 框架的竞争点就会从“谁接的模型多”转向“谁的上下文管理更高效”。所以如果你正在做 Agent 框架或者重度使用 Agent，现在就要开始思考：

• 哪些历史消息可以压缩？
• 工具结果应该原样保留还是摘要化？
• 用户在长时间对话中的意图变化如何捕捉？
• 上下文预算如何动态分配？

这些问题的答案，最终会内化到下一代 Agent 框架的核心能力里。

9. 总结：MHS 是标准之争，更是 Agent 基础设施之争

回到开头的问题：MHS 为什么值得你关注？

因为它揭示了 AI 行业一个正在进行的重要转向——从模型性能的单点竞争，转向围绕模型开发效率、协作能力、治理能力的系统性竞争。模型再强，如果接入成本高、工具生态封闭、交互链路不透明，企业依然不会大规模采用。MHS 就是这套系统性竞争中，Anthropic 打出的关键一张牌。

对于普通开发者，我的建议很明确：

1. 今天不必急着迁移任何东西，但要开始关注 MHS 的动态。
2. 在架构上做好解耦，尤其是工具定义层和执行层，这是未来最大的兼容性瓶颈。
3. 把可观测性和审计能力前置，这是无论任何标准落地都成立的最佳实践。
4. 如果遇到 Anthropic API 连接类问题，按本文的排查表和重试策略提前做好防御。

标准的制定是一场长跑，MHS 目前只是完成了起跑动作。但方向已经清晰：未来 Agent 开发的核心竞争力，不是“更懂某一家模型的私有格式”，而是“更高效地组织模型、工具和上下文之间的协作”。这值得每一位做 AI 应用的开发者持续跟进。

建议收藏这篇文章，等到 MHS 的正式文档出来之后，再回来对照看一遍，你会有更直观的感受。