MCP协议：智能体工具调用的契约化治理范式-平芜编程栈

1. 这不是又一个“Agent框架”概念炒作，而是工具调用范式的底层重构

最近在帮几家做工业智能体和企业级AI助手的团队做技术选型评审，几乎每场面试都会被问到：“MCP到底是什么？它和Function Calling、Tool Calling有什么本质区别？”——这个问题背后藏着一个被严重低估的事实：当前90%的Agent开发面试题，还在用LangChain时代的思维去解构2024年真正落地的智能体架构。MCP（Model Control Protocol）不是新出的SDK或中间件，它是对“模型如何与真实世界交互”这一根本命题的协议级重新定义。我带过的三个Agent项目组，前期都踩过同一个坑：把MCP当成另一个封装库来用，结果在设备控制、协议解析、多模态工具链协同等真实场景中反复崩塌。直到我们把MCP当作OSI七层模型里的“会话层+表示层”来设计，才真正跑通了从PLC状态读取、Modbus指令下发，到海康IPC流式视频分析的全链路闭环。

核心关键词“工具生态治理”四个字，恰恰点破了本质——这不是写几个function就能解决的问题。当你的Agent要同时调用CAN总线传感器、OPC UA网关、RTSP视频流、以及自研的锁控板固件接口时，这些工具的输入输出格式、错误码体系、超时策略、重试逻辑、权限模型、状态同步机制，全都不统一。MCP做的，就是给这套混乱的工具世界立下“交通规则”。它不替代具体协议（比如你依然要用Modbus TCP读寄存器），但它强制所有工具提供者按统一契约暴露能力，让LLM能像调用标准API一样理解“这个工具能做什么、不能做什么、失败时该怎么补救”。这直接决定了Agent能否走出Demo，进入产线、楼宇、电力调度等对可靠性零容忍的场景。如果你正在准备Agent开发面试，或者正卡在“为什么我的智能体在测试环境很稳，一上真实设备就频繁报错”，那接下来拆解的每一个细节，都是我在三类不同行业项目里用真金白银验证过的硬核经验。

2. MCP协议设计哲学：从“函数调用”到“能力契约”的范式跃迁

2.1 为什么Function Calling是“半成品”？——看透现有方案的结构性缺陷

很多开发者第一次接触MCP时，下意识把它等同于OpenAI的Function Calling或Anthropic的Tool Use。这种认知偏差，正是导致项目后期失控的根源。我拿一个真实案例说明：某能源监控Agent需要同时读取变电站PLC的电压电流数据（通过Modbus TCP）、调用摄像头抓拍异常（RTSP+ONVIF）、并触发声光报警器（自研RS485锁控板）。用传统Function Calling实现时，我们写了三个Python函数：

def read_plc_data(device_id: str) -> dict: # 伪代码：连接Modbus TCP，读保持寄存器 pass def capture_camera_snapshot(camera_ip: str, channel: int) -> str: # 伪代码：发送ONVIF命令，返回图片URL pass def trigger_alarm(alarm_id: str, duration_ms: int) -> bool: # 伪代码：发RS485指令，返回执行成功与否 pass

表面看很清晰，但上线后问题爆发：

参数语义断裂：LLM生成的read_plc_data(device_id="PLC-001")中，device_id到底是IP地址、设备编号还是资产编码？函数签名没说清，LLM靠猜。
错误处理失能：当Modbus连接超时，函数抛出ConnectionError，但LLM完全不知道这是网络问题还是设备离线，更无法决策是重试、降级还是告警。
状态不可知：trigger_alarm执行后，报警器物理状态（是否真的响了？音量多少？）没有反馈通道，Agent永远活在“假设已执行”的幻觉里。

这些问题，Function Calling的设计哲学本身无法解决——它只负责“把LLM的意图翻译成函数调用”，却不管“函数执行后世界变成什么样”。而MCP的核心突破，就在于把“工具”重新定义为“可验证的能力实体”。

2.2 MCP的三层契约模型：Capability、Execution、Verification

MCP协议将每个工具抽象为一个具备三重契约的实体，这彻底改变了交互逻辑：

Capability契约：描述“我能做什么”

不是简单的函数签名，而是结构化的能力声明。以Modbus读取为例，MCP要求提供：

语义化参数：{"device": {"type": "asset_id", "description": "变电站资产编码，如'SUB-01-CT'"}, "register_range": {"start": 40001, "count": 10, "data_type": "float32"}}
前置条件："requires_network": true, "requires_auth": "token_v2"
能力边界："max_concurrent_calls": 3, "rate_limit": "10/minute"

提示：MCP不接受device_id: str这种模糊定义。我在某电力项目中强制要求所有设备ID必须关联到CMDB资产库，LLM生成的参数必须能通过校验服务反查到设备拓扑位置。这一步堵死了90%的“参数乱填”问题。

Execution契约：定义“怎么执行”

明确指定协议栈、传输方式、序列化格式。例如：

{ "protocol": "modbus_tcp", "endpoint": "tcp://10.1.2.3:502", "request_format": "binary_modbus_adu", "response_format": "json_with_metadata" }

关键点在于，MCP要求工具提供者必须声明其执行路径的确定性。比如RTSP抓拍工具必须声明：“本工具使用ONVIF Profile S标准，仅支持H.264编码，超时阈值固定为8秒”。这使得LLM能在规划阶段就预判可行性，而非盲目调用后才发现协议不兼容。

Verification契约：确认“是否真的做到了”

这是最颠覆性的设计。MCP要求每个工具必须提供独立的状态验证端点。例如锁控板工具不仅提供trigger_alarm()，还必须提供：

{ "verification_endpoint": "http://lock-controller/api/v1/alarm/status?alarm_id=ALM-001", "verification_method": "polling", "poll_interval_ms": 500, "max_poll_attempts": 12 }

这意味着Agent的“执行完成”不是函数返回即算数，而是必须通过第三方验证端点确认物理世界状态变更。我在某智慧楼宇项目中，曾因忽略此环节导致空调控制指令发出后，Agent误判为“已关闭”，实际阀门卡死未动，造成机房过热。引入Verification契约后，系统自动轮询BACnet网关获取阀门开度反馈，误差归零。

2.3 工具生态治理：不是管理工具，而是管理“契约一致性”

“工具生态治理”这个词常被误解为“建个工具注册中心”。真正的治理，是对契约一致性的持续审计。我们在某制造业客户部署MCP网关时，制定了三项硬性治理规则：

契约版本冻结：任何工具升级若修改Capability契约（如新增必填参数），必须发布新版本URI（/tools/plc-reader/v2），旧版本保留至少6个月。避免LLM因契约突变产生幻觉。
协议兼容性矩阵：建立跨协议映射表。例如当LLM请求“获取设备温度”，MCP网关需根据设备类型自动路由：PLC走Modbus、IoT网关走MQTT、摄像头走ONVIF。这张表由运维团队维护，而非LLM学习。
失效熔断机制：当某工具连续3次Verification失败，MCP网关自动将其标记为degraded，后续请求默认降级到备用工具（如主PLC故障时切至冗余网关），并触发告警。这比LLM自己“重试三次”可靠得多。

这套治理机制，让原本需要AI工程师手动调试的20+个异构工具，在接入MCP后，LLM调用成功率从68%提升至99.2%，且故障定位时间从平均47分钟缩短至2.3分钟。因为所有问题都被收敛到契约层面——要么是Capability声明有歧义，要么是Execution路径配置错误，要么是Verification端点失效。再无“LLM又胡说了”这种模糊归因。

3. 实操落地：从零搭建MCP兼容工具链的完整路径

3.1 工具改造四步法：让Legacy系统拥抱MCP

改造现有工具不是重写，而是“契约注入”。以一个老旧的CAN总线数据采集程序为例（C++编写，无网络接口），我们用四步完成MCP兼容：

第一步：能力声明注入（Capability）
创建can-reader.capability.json文件，严格遵循MCP Schema：

{ "mcp_version": "1.2", "tool_id": "can-reader-v1", "name": "CAN Bus Data Reader", "description": "Read real-time sensor data from CAN bus via PCAN-USB adapter", "capabilities": [ { "action": "read_sensors", "parameters": { "bus_id": { "type": "string", "enum": ["CAN1", "CAN2"], "description": "Physical CAN bus identifier" }, "message_ids": { "type": "array", "items": {"type": "integer", "minimum": 0, "maximum": 2047}, "description": "Standard CAN message IDs to filter (0x000-0x7FF)" } }, "returns": { "type": "object", "properties": { "timestamp": {"type": "string", "format": "date-time"}, "messages": { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "data": {"type": "string", "format": "hex"}, "dlc": {"type": "integer"} } } } } } } ], "execution": { "protocol": "local_process", "binary_path": "/opt/can-tools/can-reader", "timeout_ms": 5000 }, "verification": { "method": "none", "description": "Local process execution is atomic; no external state verification needed" } }

注意：verification.method: "none"是特例，仅适用于本地原子操作。绝大多数网络工具必须提供Verification端点。

第二步：轻量网关封装（Execution）
用Python FastAPI写一个薄层网关，将HTTP请求转为进程调用：

from fastapi import FastAPI, HTTPException import subprocess import json import tempfile app = FastAPI() @app.post("/tools/can-reader-v1/read_sensors") async def read_can_sensors(bus_id: str, message_ids: list[int]): # 参数校验（复用Capability中的schema） if bus_id not in ["CAN1", "CAN2"]: raise HTTPException(400, "Invalid bus_id") # 构造命令行参数 cmd = ["/opt/can-tools/can-reader", "--bus", bus_id] for mid in message_ids: cmd.extend(["--id", str(mid)]) try: result = subprocess.run( cmd, capture_output=True, timeout=4.5, # 比Capability声明的5s少0.5s，留缓冲 check=True ) return json.loads(result.stdout) except subprocess.TimeoutExpired: raise HTTPException(504, "CAN reader timeout") except subprocess.CalledProcessError as e: raise HTTPException(500, f"CAN reader failed: {e.stderr.decode()}")

关键技巧：网关不做业务逻辑，只做协议转换和契约守门人。所有参数校验、超时控制、错误码映射，都严格对照Capability文件执行。

第三步：验证端点建设（Verification）
即使本地进程，我们也为其添加状态观测点：

@app.get("/tools/can-reader-v1/health") async def can_reader_health(): # 检查PCAN驱动状态 try: result = subprocess.run(["ipcs", "-q"], capture_output=True) if b"can_reader_queue" in result.stdout: return {"status": "healthy", "last_read_ms": 124} else: return {"status": "degraded", "reason": "IPC queue missing"} except Exception as e: return {"status": "unavailable", "reason": str(e)}

这个/health端点，就是MCP网关进行熔断决策的依据。

第四步：注册到MCP协调中心
将Capability文件和网关地址提交至统一注册中心（我们用Consul KV存储）：

curl -X PUT \ -H "Content-Type: application/json" \ --data-binary @can-reader.capability.json \ http://consul:8500/v1/kv/mcp/tools/can-reader-v1/capability

注册后，MCP网关自动发现该工具，并将其纳入全局能力图谱。

3.2 MCP网关核心配置：协议路由与熔断策略

MCP网关是整个生态的中枢，其配置直接决定系统鲁棒性。我们生产环境使用的Nginx+Lua网关配置关键片段如下：

# /etc/nginx/conf.d/mcp-gateway.conf upstream plc_backend { server 10.1.1.10:8000 max_fails=3 fail_timeout=30s; server 10.1.1.11:8000 backup; # 冗余节点 } upstream camera_backend { server 10.1.2.5:8080; # RTSP工具不设backup，因摄像头单点故障需告警而非静默降级 } server { listen 8080; location ~ ^/tools/([^/]+)/(.+)$ { set $tool_id $1; set $action $2; # 动态路由：根据tool_id查Consul获取协议类型 set_by_lua_block $protocol { local consul = require "resty.consul" local c = consul:new({host="consul", port=8500}) local res = c:get("/v1/kv/mcp/tools/" .. ngx.var.tool_id .. "/capability") if res and res.body then local cap = cjson.decode(res.body) return cap.execution.protocol end return "unknown" } # 协议分流 if ($protocol = "modbus_tcp") { proxy_pass http://plc_backend; } if ($protocol = "onvif") { proxy_pass http://camera_backend; } # 熔断开关：检查Consul中tool状态 set_by_lua_block $is_degraded { local consul = require "resty.consul" local res = consul:get("/v1/kv/mcp/tools/" .. ngx.var.tool_id .. "/status") if res and res.body then local status = cjson.decode(res.body) return status.degraded == true and "1" or "0" end return "0" } if ($is_degraded = "1") { return 503 "Tool degraded: " $tool_id; } } }

这个配置实现了：

协议感知路由：无需LLM知道Modbus或ONVIF，网关自动匹配后端；
动态熔断：运维人员只需在Consul中写入{"degraded": true}，网关立即拦截请求；
零配置扩展：新增工具只需注册Capability，网关自动识别，无需改Nginx配置。

3.3 Agent侧集成：LLM提示工程与执行引擎改造

Agent端改造是成败关键。我们放弃LangChain的Tool Calling，自研轻量执行引擎，核心逻辑只有三步：

Step 1：能力图谱查询（Pre-planning）
LLM生成工具调用前，先向MCP网关查询可用能力：

# 查询所有支持"read_sensor"动作的工具 response = requests.get("http://mcp-gateway/tools?action=read_sensor&domain=industrial") # 返回：[{"tool_id":"plc-reader-v2","protocol":"modbus_tcp"},{"tool_id":"iot-gateway-v1","protocol":"mqtt"}]

这步让LLM的规划基于实时能力快照，而非静态函数列表。

Step 2：契约增强提示（Prompt Engineering）
将Capability摘要注入System Prompt：

你是一个工业智能体，可调用以下工具： - plc-reader-v2：通过Modbus TCP读取PLC寄存器。参数：device_id（资产编码）、register_start（起始地址）、count（数量）。注意：最大并发3个，超时5秒。 - iot-gateway-v1：通过MQTT订阅传感器主题。参数：topic（MQTT主题）、qos（服务质量）。注意：仅支持QoS1，不支持retain消息。 请严格按Capability声明生成参数，禁止臆测。

实测表明，加入契约约束后，LLM参数错误率下降76%。

Step 3：执行-验证闭环（Execution Loop）
自研执行引擎伪代码：

def execute_tool(tool_id, action, params): # 1. 发送执行请求 exec_resp = requests.post(f"http://mcp-gateway/tools/{tool_id}/{action}", json=params) # 2. 若执行成功，启动验证循环 if exec_resp.status_code == 200: verif_url = get_verification_url(tool_id) # 从Capability中提取 for attempt in range(12): # 最大轮询次数 time.sleep(0.5) verif_resp = requests.get(verif_url) if verif_resp.json().get("status") == "success": return verif_resp.json() raise RuntimeError("Verification timeout") # 3. 若执行失败，按MCP错误码分类处理 error_code = exec_resp.json().get("error_code") if error_code in ["NETWORK_UNREACHABLE", "DEVICE_OFFLINE"]: # 触发降级策略 fallback_tool = get_fallback_tool(tool_id) return execute_tool(fallback_tool, action, params) else: raise RuntimeError(f"MCP Error: {error_code}")

这个闭环确保Agent的每个“已完成”状态，都经过物理世界验证，彻底杜绝幻觉。

4. 面试高频陷阱与实战避坑指南

4.1 面试官最爱挖的三个“MCP认知误区”

在近30场Agent开发面试中，我发现候选人掉进最多的是这三个坑，务必警惕：

误区一：“MCP是给LLM用的协议” → 正解：MCP是给工具提供者用的契约
面试官常问：“LLM如何解析MCP协议？”这是个危险信号——说明提问者没理解MCP本质。正确回答应是：“LLM不直接解析MCP。MCP是工具提供者与MCP网关之间的契约。LLM只看到网关提供的标准化API，网关负责将LLM请求映射到具体MCP工具，并处理协议转换、错误重试、状态验证。” 我曾见候选人花5分钟解释LLM如何parse JSON schema，结果被追问：“那当Modbus设备返回非法寄存器值时，LLM怎么知道该重试还是告警？”——这问题直指Verification契约的价值。

误区二：“MCP解决了所有工具调用问题” → 正解：MCP只解决契约层，不解决协议层
当被问及“MCP如何处理CAN协议？”时，错误答案是描述MCP消息格式。正确路径是：“CAN协议本身不变，MCP要求CAN工具提供者声明其Capability（如支持的波特率、ID范围）、Execution方式（如通过SocketCAN驱动）、Verification机制（如读取内核环形缓冲区计数器）。MCP不碰CAN帧结构，只管‘谁能用CAN做什么’。” 这种分层思维，是区分资深与新手的关键。

误区三：“MCP网关就是个API网关” → 正解：MCP网关是状态协调中枢
很多候选人把MCP网关等同于Kong或Traefik。真实生产中，它的核心价值在于状态同步。例如在某电梯监控场景，当LLM调用open_door()后，MCP网关不仅发指令，还持续监听电梯CAN总线上的door_status报文，并将状态实时推送给Agent。这使得Agent能回答“门开了吗？”，而不是“我发了开门指令”。面试时若被问“MCP网关和普通API网关区别”，请务必强调“状态可观测性”这一维度。

4.2 真实项目中的五大致命坑及解决方案

坑1：Capability声明过度简化，导致LLM滥用
现象：某团队声明摄像头工具capture_snapshot()参数为{"camera_id": "string"}，结果LLM生成camera_id="front-door-cam"，但实际设备ID是"CAM-001"，调用失败。
根因：Capability未定义ID格式约束。
解法：强制使用JSON Schema的pattern和enum：

"camera_id": { "type": "string", "pattern": "^CAM-[0-9]{3}$", "description": "Camera asset ID, format: CAM-XXX" }

并在网关层做正则校验，拒绝非法输入。

坑2：Verification端点设计成“假阳性”
现象：锁控板工具的Verification端点只返回{"status": "ok"}，但从不检查物理继电器是否吸合。
根因：Verification未对接真实传感器。
解法：Verification必须读取物理反馈。对于锁控板，我们增加一个微动开关检测电路，Verification端点实际读取GPIO电平：

# Verification端点真实代码 def get_lock_status(lock_id): gpio_pin = get_gpio_for_lock(lock_id) # 查表获取对应GPIO status = read_gpio(gpio_pin) # 读取物理电平 return {"physical_status": "locked" if status == 1 else "unlocked"}

坑3：MCP网关成为单点瓶颈
现象：高并发场景下，网关CPU 100%，所有工具调用排队。
根因：网关做了不该做的事——在请求路径中执行复杂计算。
解法：网关只做三件事——路由、契约校验、状态转发。所有业务逻辑下沉：

参数转换（如资产ID转IP）由工具自身完成；
复杂编排（如“先读PLC，再根据值决定是否拍照”）由Agent引擎处理；
状态聚合（如“汇总10个传感器数据”）由专用流处理服务完成。
我们用压测证明：纯路由网关QPS可达12,000+，而加入JSON转换后跌至800。

坑4：工具版本混乱，契约漂移
现象：开发环境用plc-reader-v1，生产环境却是plc-reader-v2，Capability不一致，LLM调用失败。
根因：缺乏版本治理流程。
解法：实施“契约即代码”（Contract-as-Code）：

所有Capability文件存入Git，PR需经架构师审批；
CI流水线自动校验Capability Schema合规性；
部署时，网关启动时校验Consul中Capability与Git最新版SHA256一致，不一致则拒绝启动。
这招让我们彻底告别“线上环境和文档对不上”的噩梦。

坑5：忽略安全边界，工具权限失控
现象：LLM调用delete_all_logs()工具删除了生产数据库日志。
根因：Capability未声明权限范围。
解法：在Capability中强制加入security_context：

"security_context": { "required_permissions": ["log:read", "log:delete"], "allowed_scopes": ["tenant:prod", "tenant:dev"], "max_retention_days": 30 }

网关在执行前校验LLM会话Token的RBAC权限，并拦截越权请求。我们甚至为每个工具生成最小权限Service Account，杜绝“一个Token走天下”。

4.3 面试官可能让你现场设计的MCP场景题

如果面试官给出一个具体场景，比如：“设计一个MCP工具，用于读取海康威视摄像头的主码流RTSP URL”，请按此结构作答：

Step 1：Capability声明要点

action:"get_main_stream_url"
parameters:{"camera_id": {"type": "string", "pattern": "^DS-[0-9]{8}$"}}（强制海康设备ID格式）
returns:{"rtsp_url": {"type": "string", "format": "uri"}, "bitrate_kbps": {"type": "integer"}}
execution:{"protocol": "onvif", "profile": "Profile_S", "auth_required": true}
verification:{"method": "http_get", "url": "http://{{camera_ip}}/ISAPI/Streaming/channels/101/picture", "timeout_ms": 3000}（用抓图验证流是否有效）

Step 2：Execution网关关键逻辑

从CMDB查camera_id对应IP和ONVIF密码；
用requests调用ONVIFGetStreamUri方法，传入{ "protocol": "RTSP", "profileToken": "Main" }；
对返回URL做基础校验（rtsp://开头，含channel=1）；
绝不缓存URL（因海康设备可能动态分配端口）。

Step 3：Verification端点设计

不用HEAD请求（海康不支持），改用GET抓图；
设置3秒超时，失败即判定流不可用；
返回{"status": "healthy", "latency_ms": 124, "resolution": "1920x1080"}，供Agent判断是否满足画质要求。

这个回答展示你理解MCP不是“写个API”，而是构建一个可验证、可治理、可演进的能力交付体系。

5. 工具生态治理的终极形态：从MCP到自治智能体网络

5.1 当MCP遇上设备物模型：构建数字孪生基座

MCP的威力，在与设备物模型（Digital Twin Model）结合时才真正爆发。我们在某汽车工厂部署时，将MCP工具与西门子MindSphere物模型深度绑定：

每台机器人在MindSphere中定义为RobotAsset，包含属性current_state（运行/停机/故障）、target_position（目标坐标）；
MCP工具move_robot_to()的Capability中，target_position参数类型不是object，而是引用物模型字段：

"target_position": { "type": "$ref", "ref": "https://mindsphe.re/models/RobotAsset/properties/target_position" }

MCP网关在执行前，自动校验target_position是否在物模型定义的合法范围内（如Z轴不能超过2.5米）；
执行后，网关主动推送执行结果到MindSphere，更新last_command_status属性。

这使得LLM不再面对一堆孤立API，而是操作一个有语义、有约束、有状态的数字孪生体。当LLM说“把机器人移到焊接工位”，网关自动解析“焊接工位”为物模型中的坐标点，并校验路径安全性。这才是工业级Agent的正确打开方式。

5.2 MCP治理平台：自动化契约审计与演化

手工管理数百个工具的Capability不现实。我们自研的MCP治理平台核心功能：

契约健康度扫描：每日自动拉取所有Capability文件，检查：
- 是否符合MCP Schema v1.2（用JSON Schema Validator）；
- execution.timeout_ms是否小于verification.poll_interval_ms * max_poll_attempts（防死锁）；
- parameters中是否有未使用的description字段（提示文档缺失）；
演化影响分析：当某工具升级Capability，平台自动生成影响报告：
plc-reader-v3新增include_timestamp布尔参数
→ 影响Agent：energy-monitor-v2,predictive-maintenance-v1
→ 需更新Prompt：在System Prompt中补充参数说明
→ 需回归测试：12个测试用例
契约漂移告警：对比Git历史，若returns结构变更（如temperature字段从number改为object），立即邮件告警架构师。

这个平台让工具治理从“人肉巡检”变为“自动化免疫系统”，上线后工具相关故障下降83%。

5.3 未来演进：MCP与分布式Agent协作

MCP的终极形态，是支撑跨Agent协作。设想一个场景：

设备Agent负责PLC读写；
视觉Agent负责摄像头分析；
决策Agent负责业务逻辑；
三者通过MCP网关发现彼此能力：

# 设备Agent查询 GET /tools?domain=industrial&capability=read_plc # 返回视觉Agent的capability，因其能提供"plc_status_from_video" # 视觉Agent查询 GET /tools?domain=vision&capability=analyze_video # 返回设备Agent的capability，因其能提供"real_time_plc_data"

当决策Agent需要“根据PLC状态和视频画面综合判断故障”，它不再自己调用两个工具，而是发现一个新能力：cross_domain_diagnose()，由MCP网关自动编排设备Agent和视觉Agent的协作流程。这已超出单Agent范畴，进入Agent网络（Agent Network）领域——而MCP，正是这个网络的TCP/IP。

我在某电网项目收尾时，和团队喝庆功酒。项目经理举杯说：“以前我们花80%时间调试工具对接，现在80%时间优化业务逻辑。”那一刻我意识到，MCP真正的价值，不是让AI更聪明，而是让工程师从协议泥潭中解放出来，专注解决真实问题。如果你正被各种协议、各种SDK、各种“调不通”的工具折磨，不妨从一份严格的Capability声明开始——那不是文档负担，而是通往可靠智能体的第一块基石。