前一章谈的是“从模型视角理解 Agent”，这一章要进一步回答一个更工程的问题：如果模型不是单一能力体，那么我们到底该如何描述它，才能真正服务于设计、选型、评测与交付。
答案就是能力画像。
能力画像不是宣传页上的参数罗列，也不是排行榜上的总分排名，而是一种可被系统设计直接消费的能力拆解方式。它把“这个模型大概很强”改写成“它在哪些维度足够强、在哪些维度仍然脆弱、这些强弱如何影响 Agent 的系统行为”。
这是一个很关键的转折。因为在 Agent 系统中，模型不再只是一个会回答问题的核心组件，而是一个要参与推理、规划、调用工具、生成结构、吸收反馈、跨轮保持一致、接入多模态输入、满足时延要求的工作节点。只用一个“聪明”或“不聪明”来概括它，已经远远不够。
所以，能力画像真正解决的，是抽象模型讨论和实际系统设计之间的断层。
一个成熟的能力画像，至少应该覆盖六个维度：推理、工具调用、结构化输出、长上下文、多模态、实时性。它们彼此相关，但不能相互替代；它们会共同塑造 Agent 的行为上限，也会共同决定系统失败会发生在哪个环节。
先看推理能力。
推理能力不是“回答得像不像人”，而是模型能否在多步条件、隐含约束、冲突信息和不完整证据之间，持续形成可执行判断。很多经典评测已经反复说明，推理不是一个可以被语言流畅性掩盖的问题。模型可能写得很像会思考，但在数学、多步逻辑、抽象模式归纳、专业科学问答这类任务中，仍然会暴露出明显的能力断层。
这意味着，对于 Agent 来说，推理能力的意义不在“答题更漂亮”，而在是否能支持规划与决策。一个需要拆解任务、识别条件冲突、比较多个候选路径、处理局部失败后再规划的 Agent，如果底层模型没有足够稳定的推理能力，就会在系统层表现为路线选择反复摇摆、步骤顺序不稳定、局部结论无法合并为整体判断。
但推理能力也不能被神化。它解决的是“怎么想”的问题，不自动解决“怎么做”的问题。很多团队把推理模型看成万能底座，结果发现系统仍然不稳，就是因为他们忽略了另一个同样独立的重要维度：工具调用。
工具调用能力，绝不是“会不会输出一个函数名”。它至少包含五件事：是否知道什么时候应该调用工具，是否能从多个候选工具中选对一个，是否能把参数填完整，是否能基于工具返回结果继续下一步动作，以及是否能在多轮多工具链条里保持状态一致。
这一点在近两年的工具基准中已经非常清楚。真实的 Agent 工具使用，不是单轮 demo 里那种“用户说天气，模型调用天气 API”这么简单，而是经常包含缺失参数澄清、规则约束、连续调用、失败恢复、跨步依赖、长上下文记忆等复杂因素。也就是说，工具调用能力本质上更像一种“受环境约束的行动能力”，而不是格式化输出能力的附属品。
因此，判断一个模型的工具能力，不能只看它能不能吐出一个看似正确的调用片段，而要看它在完整闭环中的稳定性。很多模型在离线样例里看起来很会调工具，但进入多轮现实场景后，就会开始出现乱选工具、遗漏参数、误解返回值、重复调用甚至跳过约束条件的问题。
接着是结构化输出能力。
这是最常被低估，却在工程里最早出问题的维度之一。因为 Agent 一旦进入生产系统，它往往不只是和人对话，还要把结果交给数据库、消息队列、审批链路、前端组件、自动化系统或者其他 Agent。此时，输出若不能稳定地符合 schema，整个系统就会频繁中断。
但结构化输出要注意一个常见误区：格式正确，不等于语义正确。
近来的各家官方能力建设都在强调 schema adherence，也就是尽量保证输出严格满足定义好的 JSON Schema 或工具参数结构。这对工程稳定性非常关键，因为它能显著降低解析失败、字段缺失、类型漂移这类低层故障。但它并不能自动保证业务判断正确。模型完全可能给出一个字段齐全、类型正确、格式无误的 JSON，同时在分类结论、风险等级、工具参数意义上仍然犯错。
所以，结构化输出能力的价值，在于把系统失败从“连管道都接不上”推进到“至少可以进一步检查语义是否可靠”。它解决的是接口稳定性，不直接替代业务校验、规则校验和后验验证。
第四个维度是长上下文能力。
很多人一看到长上下文，就立刻把它理解成窗口大小。这个理解太浅了。真正有价值的长上下文能力，不是“能塞进更多 token”，而是“在更长的信息链里仍然能找对东西、保持重点、压制噪声、维持前后一致”。如果一个模型虽然支持超长窗口，却在长文档里抓不住关键证据，在上下文中段丢失重要约束，或者被局部冗余信息带偏，那么这个窗口扩展对 Agent 的实际帮助就会非常有限。
相关研究已经多次指出，长上下文环境中的真正难题包括：信息位置敏感、关键证据在中间段被忽视、检索和整合能力不对称、长序列推理退化，以及记忆机制和推理机制之间并未自然统一。这也是为什么一个看起来“窗口很大”的模型，在真实文档 Agent 里仍可能表现平平。
所以，从 Agent 角度看，长上下文能力至少要拆成三个问题：能否在长材料中精确定位证据，能否跨段整合多处信息，能否在长链交互里维持状态一致。只有这三个问题都足够好，长上下文才真正转化成系统能力。
第五个维度是多模态能力。
在纯文本时代，我们谈 Agent，通常默认它处理的是语言和文档。但今天大量高价值场景已经不是这样了。客服面对的是语音与截图，办公助手面对的是表格、文档、图像和界面，工业系统面对的是视频流和传感器，教育与医疗场景里还可能同时包含语音、图像、结构化记录与历史文本。
这意味着，多模态能力不再是可有可无的附加项，而是在很多任务中直接决定 Agent 是否“看得见世界”。如果模型只能处理文本，那么它面对复杂表格、扫描文档、界面截图、视频片段和语音流时，要么依赖外部系统做强预处理，要么天然失去一部分上下文。反过来，如果模型能够直接吸收和联立这些信息，它就能把“理解任务”从单文本问题升级成对现实工作环境的理解。
不过，多模态也不是简单的“支持图片输入”即可。真正重要的是跨模态统一理解能力，也就是模型能否把图像中的证据、文本中的规则、语音中的意图和结构化系统中的状态整合成同一个任务判断。Agent 在多模态环境里最怕的不是某一种模态单独看不懂，而是不同模态之间不能形成统一状态。
第六个维度是实时性。
实时性本质上是在问：模型能力能否在产品允许的交互时限内交付出来。这个问题在过去常被忽视，因为很多人默认“质量第一，慢一点没关系”。但一旦进入语音助手、实时客服、会议同传、驾驶舱助手、交易协同、工业监控等场景，时延本身就变成系统体验的一部分，甚至变成系统可用性的门槛。
所以，实时性不能只被理解成“跑得快”。它实际上同时关联首 token 延迟、连续输出稳定性、工具调用往返耗时、流式交互能力、语音端到端响应，以及在低时延条件下模型能力是否明显退化。很多模型在离线任务上表现很好，但一放进实时链路中，就会因为推理太慢、工具链太长、上下文太重而失去产品价值。
到了这里，一个关键结论就出来了：这六个维度虽然相关，却并不共线。
推理强，不代表工具调用稳。工具调用稳，不代表结构化输出一定严格。长上下文大，不代表真正能在长文档里持续找准重点。多模态全，不代表实时交互足够快。实时足够快，也不代表复杂规划能力足够深。
这正是“能力画像”相对于“模型排名”的价值所在。它迫使我们承认，模型不是一个单分数对象，而是一个能力向量。Agent 设计要做的，也不是追求某个总榜第一，而是为具体任务找到合适的能力组合。
从产品和工程视角看，能力画像还有第二层作用：它能把架构讨论前移。
如果你先建立画像，就会更容易发现哪些问题该交给模型，哪些问题不该交给模型。例如，一个审批 Agent 如果主要困难来自输出稳定性和业务约束执行，那么你就应该优先强化 schema、规则引擎和校验链，而不是一味升级更强的推理模型。一个知识研究 Agent 如果真正的瓶颈是长文档证据定位和多轮信息整合，那么重点也许是检索、切片和上下文管理，而不只是更换参数更大的模型。
也就是说，能力画像不仅帮助选模型，也帮助识别“问题究竟是不是模型问题”。
这一点已经越来越明显地反映在各家官方文档的组织方式里。现在领先厂商对模型的展示，不再只是“更强、更快、更便宜”的单句比较，而会明确区分 reasoning、tools、context、latency、multimodal、structured outputs 等能力面板。这实际上是在引导开发者不要把模型当成抽象智能体，而要把它当成可被系统拆解和匹配的能力模块。
因此，在真正做 Agent 设计时，一个更成熟的顺序应该是：
- 先定义任务需要什么能力组合
- 再定义这些能力组合需要怎样的系统补强
- 最后才去匹配模型与架构
例如，一个面向企业知识库的研究型 Agent，可以先写出这样一份能力画像：
- 推理深度：中高，因为需要比较多个证据并形成结论
- 工具调用：高，因为必须稳定调用检索、引用、数据库和工作流接口
- 结构化输出：高，因为下游系统依赖稳定字段与引用结构
- 长上下文：高，因为要处理长文档、多文档与多轮任务链
- 多模态：中，若涉及 PDF、表格、截图则需要增强
- 实时性：中，因为可以容忍数秒级延迟换取质量
有了这张画像，后面的选型与系统设计就会变得清晰得多。你不再是先看谁最火，而是看谁在这六个维度上与任务最匹配，谁的短板又能被系统层补掉。
这就是本章真正要建立的认识：模型能力画像不是对模型做介绍，而是把模型重新纳入 Agent 工程。只有当模型被描述成一个多维能力组合，Agent 的设计、评测、运维和迭代，才会真正进入可控状态。