1. 从单模态到多模态Agent 感知能力的质变1.1 为什么纯文本 Agent 越来越不够用过去一年我一直在做 Agent 相关的开发最开始接触的都是纯文本场景——用户输入一段话模型理解意图调用工具返回结果。这套链路跑通之后确实能解决不少问题比如自动整理文档、批量处理表格数据、根据自然语言生成代码片段。但做着做着就发现真实业务场景里纯文本的覆盖面太窄了。举个很典型的例子。我帮一个做电商的朋友搭过一套客服辅助系统最初的版本只能处理文字咨询。结果上线第一周就发现大量用户发的是商品截图问“这个还有货吗”“这个和那个有什么区别”。纯文本 Agent 面对图片直接抓瞎只能回复“请用文字描述您的问题”用户体验极差。后来我们接入了多模态能力让 Agent 能直接读图整个系统的可用性才上了一个台阶。这个经历让我意识到一个核心问题Agent 要真正在业务里落地感知能力必须覆盖人类日常交流的主要模态。人类沟通从来不是纯文字的截图、语音、视频、手绘草图都是信息载体。Agent 如果只能处理文本相当于蒙着一只眼睛干活。1.2 多模态能力到底包含哪些维度很多人一提多模态就想到“能看图”这个理解太窄了。从我这段时间的实践来看多模态至少包含以下几个维度视觉理解识别图片中的物体、场景、文字、图表、界面元素视觉推理基于图片内容做逻辑判断比如对比两张图的差异、判断图表趋势文档解析从 PDF、扫描件、截图中提取结构化信息包括表格、公式、手写批注语音处理语音转文字、文字转语音、语音情感识别视频理解关键帧提取、动作识别、时序事件分析跨模态对齐把不同模态的信息映射到统一语义空间实现“以图搜文”“以文搜图”这里面每一个维度背后都是一套独立的技术栈。视觉理解依赖视觉编码器语音处理依赖声学模型视频理解还要额外处理时序信息。Agent 开发者不需要自己训练这些模型但必须理解它们的能力边界才能在设计系统时做出正确的架构决策。1.3 多模态 Agent 的典型架构长什么样我目前用的架构大致分三层。最底层是模态感知层负责把各种原始输入转成模型能理解的表示。图片走视觉编码器变成 embedding语音走声学模型变成文本视频先抽帧再逐帧处理。中间层是融合推理层把不同模态的表示对齐到同一个语义空间让大模型能统一处理。最上层是决策执行层Agent 根据融合后的理解做规划、调工具、生成回复。这个架构里最容易被低估的是融合推理层。很多人以为把图片转成文字描述再喂给大模型就行了但这样会丢失大量视觉细节。比如一张复杂的流程图文字描述很难完整还原节点之间的连接关系。更好的做法是让视觉编码器直接输出 embedding和大模型的文本 embedding 做对齐保留原始视觉信息。实操心得多模态融合不是简单的“图片转文字”而是要在表示层面做对齐。如果只是把图片描述成文字再处理那本质上还是单模态系统多模态能力会大打折扣。1.4 多模态落地时踩过的坑第一个坑是分辨率陷阱。很多视觉编码器对输入图片的分辨率有固定要求比如 224x224 或 336x336。如果直接把高分辨率截图塞进去会被强制缩放小字直接糊掉。我的做法是先做区域裁剪把关键区域单独切出来放大处理再和全图信息做融合。第二个坑是模态冲突。当图片信息和文字信息矛盾时模型该信谁我遇到过用户发了一张过期的促销截图但文字说“现在还有这个活动吗”。模型如果只看图会回答“有”只看文字会回答“不确定”。正确的做法是让模型识别出时间信息结合当前日期做判断。这需要在 prompt 里显式引导模型做交叉验证。第三个坑是成本失控。多模态推理的 token 消耗远高于纯文本一张高清图可能吃掉几千个 token。如果 Agent 每轮对话都传图成本会爆炸。我的策略是只在必要时传图比如用户明确发了图片或者任务确实需要视觉信息。其他情况用文字摘要代替。2. Harness 工程Agent 的“操作系统”到底该怎么搭2.1 Harness 是什么为什么它比模型本身还重要Harness 这个词在 Agent 开发圈里越来越热但很多人对它的理解还停留在“工具调用框架”的层面。我的理解是Harness 是 Agent 的运行环境负责管理模型、工具、记忆、状态、安全边界的一整套基础设施。它相当于 Agent 的操作系统模型只是跑在这个系统上的一个进程。为什么说 Harness 比模型本身还重要因为模型能力再强如果没有好的 Harness也发挥不出来。我见过太多团队花大价钱调模型结果 Harness 做得一塌糊涂——工具调用经常超时、上下文管理混乱、错误处理缺失最后 Agent 的表现还不如一个简单的规则引擎。反过来一个设计良好的 Harness 能让中等能力的模型表现出色。因为它能帮模型屏蔽掉大量复杂性自动重试失败的工具调用、智能裁剪上下文、在模型跑偏时及时纠偏。这些工程细节对最终效果的影响往往比换一个更强的模型还大。2.2 Harness 的核心模块拆解我自己的 Harness 实现包含以下几个核心模块工具注册与发现模块。所有可调用的工具都在这里注册包括工具名称、参数 schema、返回值格式、超时时间、重试策略。Agent 在规划时先查询可用工具列表再决定调用哪个。这个模块的关键是 schema 设计要足够清晰让模型能准确理解每个工具的用途和参数要求。上下文管理模块。负责维护对话历史、工具调用记录、中间结果。核心挑战是上下文窗口有限必须做智能裁剪。我的策略是分层管理最近几轮对话完整保留较早的对话做摘要压缩工具调用的原始结果只保留关键字段。执行调度模块。负责实际调用工具、处理并发、管理超时和重试。这个模块最容易被忽视但恰恰是稳定性的关键。我在这里加了熔断机制某个工具连续失败就暂时禁用避免 Agent 陷入死循环。状态持久化模块。Agent 的执行状态需要持久化支持中断恢复。比如一个长任务跑到一半服务重启了能从上次的状态继续跑。这个模块对生产环境至关重要。安全护栏模块。负责输入输出过滤、权限校验、敏感操作二次确认。这个模块的优先级最高任何工具调用前都要过一遍安全检查。2.3 工具调用的设计哲学工具调用是 Harness 最核心的能力但设计得好不好差别巨大。我总结了几条原则第一工具粒度要适中。太细会导致调用次数爆炸太粗会丧失灵活性。比如“读取文件”和“写入文件”应该分开但“读取 CSV 并解析成 JSON”可以合成一个工具。第二参数设计要防呆。模型很容易传错参数类型所以 schema 要尽量宽松同时在工具内部做类型转换和校验。比如日期参数同时接受字符串和时间戳工具内部统一处理。第三返回值要精简。工具返回的内容会占用上下文窗口所以只返回必要信息。比如查询数据库只返回匹配的记录不要返回整个表结构。第四错误信息要可操作。工具失败时返回的错误信息要能让模型理解问题所在并决定下一步怎么做。比如“参数 start_date 格式错误应为 YYYY-MM-DD”就比“Invalid argument”有用得多。2.4 Harness 的性能优化实战性能是 Harness 的另一个关键维度。我做过一次压测发现瓶颈主要在工具调用的网络延迟上。优化手段包括并行调用多个独立工具同时调用而不是串行等待结果缓存相同参数的调用结果缓存一段时间避免重复请求预取根据任务规划提前调用可能需要的工具降级策略主工具超时后自动切换到备用工具这些优化做完之后端到端延迟从平均 8 秒降到了 2 秒左右。对于交互式场景这个提升是决定性的。注意事项并行调用虽然快但要注意工具之间的依赖关系。有依赖的工具必须串行否则会拿到错误的结果。我在 Harness 里加了一个依赖图自动判断哪些工具可以并行。3. MCP 协议Agent 工具生态的“USB 接口”3.1 MCP 解决了什么根本问题在没有 MCP 之前每个 Agent 框架都有自己的工具定义方式。LangChain 有一套AutoGPT 有一套各家大厂的 Agent 平台又各有一套。结果是工具开发者要为每个框架写一遍适配代码Agent 开发者要维护一堆胶水层。整个生态极其碎片化。MCP 的出现相当于给这个混乱的市场定了一个标准接口。它定义了一套通用的协议让工具提供方和 Agent 消费方解耦。工具只需要实现一次 MCP 服务端所有支持 MCP 的 Agent 都能直接调用。这就像 USB 接口统一了外设连接一样意义重大。我第一次把内部工具迁移到 MCP 协议时最大的感受是“清爽”。以前每个工具都要写一堆适配代码现在只需要实现标准的 MCP 接口Agent 端自动就能发现和调用。开发效率至少提升了一倍。3.2 MCP 的核心概念与工作流程MCP 的核心概念包括Server工具提供方暴露一组能力Resources、Tools、PromptsClientAgent 端连接 Server 并调用其能力Transport通信层支持标准输入输出、HTTP 等多种方式CapabilityServer 声明自己支持的能力类型工作流程大致是Client 启动时连接 ServerServer 返回自己的能力清单。Client 把这些能力注册到本地工具列表。Agent 需要调用某个工具时Client 通过 Transport 发送请求Server 执行后返回结果。这个流程看起来简单但细节很多。比如能力发现是动态的Server 可以在运行时更新自己的能力列表Client 需要能感知到变化。再比如错误处理Server 返回的错误要能被 Client 正确解析并传递给 Agent。3.3 自己动手实现一个 MCP Server我拿一个实际场景来演示给 Agent 提供一个“查询天气”的工具。用 MCP 协议实现大致分几步。第一步定义工具 schema。包括工具名称、描述、参数列表、返回值格式。描述要写得足够清晰因为 Agent 是依据描述来决定是否调用这个工具的。{ name: get_weather, description: 查询指定城市的当前天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名称如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], default: celsius } }, required: [city] } }第二步实现工具逻辑。这部分就是普通的业务代码调用天气 API解析返回结果格式化成 MCP 要求的格式。第三步注册到 MCP Server。把工具 schema 和实现绑定声明 Server 的能力清单。第四步启动 Server 并测试。用 MCP Client 连接验证工具能被正确发现和调用。整个过程下来一个简单的 MCP Server 半天就能搞定。复杂的是错误处理、超时控制、并发管理这些工程细节。3.4 MCP 生态的现状与选型建议目前 MCP 生态还在快速演进中。官方提供了一批基础 Server 实现社区也在贡献各种工具。但整体来说成熟度还不够高生产环境使用需要谨慎。我的选型建议是内部工具优先 MCP 化自己团队的工具用 MCP 协议统一管理收益最大外部工具谨慎接入第三方 MCP Server 的质量参差不齐接入前要充分测试关键路径保留降级方案MCP 调用失败时要有备用方案不能完全依赖关注协议版本兼容性MCP 协议还在迭代升级时要注意向后兼容实操心得MCP 的最大价值在于解耦但解耦也带来了额外的网络开销和故障点。对于性能敏感的场景可以考虑把 MCP Server 和 Agent 部署在同一台机器上走本地通信。4. 三者的化学反应多模态 Harness MCP 的协同设计4.1 为什么这三者必须一起考虑单独看多模态、Harness、MCP每个都是独立的技术方向。但在实际项目中它们必须协同设计否则会出现各种割裂。举个例子。多模态 Agent 需要处理图片图片可能来自本地文件、网络 URL、或者某个 MCP 工具返回的结果。Harness 需要统一管理这些不同来源的图片做格式转换、缓存、生命周期管理。如果 Harness 没有为多模态做专门设计图片处理会变得极其混乱。再比如MCP 工具可能返回图片、音频、视频等非文本内容。Harness 需要能正确解析这些返回值并决定是直接传给模型还是先做预处理。这要求 Harness 的上下文管理模块支持多模态数据。所以我的做法是在架构设计阶段就把三者放在一起考虑而不是先搭 Harness 再补多模态最后接 MCP。这样能避免大量的返工。4.2 协同架构的具体设计我的协同架构大致是这样的输入层统一接收各种模态的输入做初步的格式检测和预处理。图片做压缩和裁剪音频做降噪和分段视频做抽帧。Harness 层负责调度。它维护一个多模态上下文把不同来源的数据统一管理。当 Agent 需要调用工具时Harness 从 MCP 注册表中查找可用工具构造请求处理返回。MCP 层提供工具能力。工具可以返回任意模态的数据Harness 负责解析和转换。模型层做融合推理。多模态 embedding 在这里对齐Agent 的决策在这里生成。这个架构的关键是 Harness 层的多模态上下文管理。我实现了一个统一的数据结构能容纳文本、图片、音频、视频等各种类型并支持按需转换。比如 Agent 需要把图片转成文字描述时Harness 自动调用视觉编码器需要把文字转成语音时自动调用语音合成。4.3 一个完整的实战案例我拿一个“智能文档助手”的案例来串一遍。用户上传一份 PDF 合同要求 Agent 提取关键条款并生成摘要。流程是这样的用户上传 PDFHarness 的输入层检测到文件类型调用文档解析工具把 PDF 转成结构化文本和图片。文本部分直接进上下文图片部分比如印章、签名走视觉编码器生成 embedding。Harness 把这两部分对齐后传给模型。模型理解任务后规划出步骤先提取条款再生成摘要。Harness 根据规划调用 MCP 工具。提取条款可能用到 OCR 工具、表格解析工具、条款分类工具。这些工具都通过 MCP 协议注册Harness 统一调度。工具返回的结果可能是文本、表格、图片。Harness 统一处理把关键信息注入上下文。模型基于这些信息生成最终摘要。整个流程涉及多模态输入、Harness 调度、MCP 工具调用三者紧密配合。任何一个环节设计不好整体效果都会打折扣。4.4 协同设计中的常见陷阱第一个陷阱是模态转换丢失信息。比如把图片转成文字描述时很多视觉细节会丢失。我的做法是保留原始图片的 embedding在需要时和文字描述一起传给模型。第二个陷阱是工具返回值格式不统一。不同 MCP 工具返回的数据格式可能不一样Harness 需要做归一化处理。我定义了一套内部标准格式所有工具返回值都转成这个格式再进上下文。第三个陷阱是上下文膨胀。多模态数据很占空间如果不加控制上下文很快就会被撑爆。我的策略是分级存储原始数据存在外部存储上下文里只放引用和摘要需要时再按需加载。第四个陷阱是错误传播。多模态处理链路很长任何一环出错都可能导致整体失败。我在每个环节都加了错误捕获和降级逻辑确保单点故障不会导致整个任务失败。5. 踩坑实录与排查技巧5.1 多模态相关的典型问题问题一图片识别准确率低。排查下来发现是图片预处理有问题。原始图片分辨率太高被视觉编码器强制缩放后细节丢失。解决方案是先做区域裁剪把关键区域单独处理。问题二模型忽略图片信息。模型有时候会“假装”看了图片实际回答还是基于文字。排查发现是 prompt 设计有问题没有显式引导模型关注图片。解决方案是在 prompt 里明确要求模型先描述图片内容再基于描述做推理。问题三多图对比效果差。让模型对比两张图片时经常出现混淆。解决方案是给每张图加唯一标识在 prompt 里明确引用标识避免模型搞混。5.2 Harness 相关的典型问题问题一工具调用超时。排查发现是某个工具的网络请求没有设超时导致整个 Agent 卡住。解决方案是所有工具调用都必须设超时并有降级方案。问题二上下文裁剪导致信息丢失。裁剪策略太激进把关键信息裁掉了。解决方案是分层裁剪优先保留工具调用结果和关键决策点。问题三状态恢复失败。服务重启后 Agent 无法从上次状态继续。排查发现是状态持久化不完整有些中间状态没有存。解决方案是完善状态快照机制定期持久化。5.3 MCP 相关的典型问题问题一Server 连接不稳定。排查发现是 Transport 层没有做重连机制。解决方案是加自动重连和心跳检测。问题二能力发现失败。Client 启动时 Server 还没准备好导致能力列表为空。解决方案是加启动重试和延迟发现机制。问题三版本不兼容。Server 升级后协议版本变了Client 无法解析。解决方案是协议版本协商Client 和 Server 启动时先交换版本信息。5.4 常见问题速查表问题现象可能原因排查方向解决方案图片识别不准分辨率不匹配检查预处理流程区域裁剪放大模型忽略图片prompt 引导不足检查 prompt 设计显式要求描述图片工具调用超时未设超时检查工具配置加超时降级上下文丢失裁剪太激进检查裁剪策略分层裁剪MCP 连接失败Transport 问题检查网络和协议重连心跳状态恢复失败持久化不完整检查快照机制完善状态存储避坑技巧多模态 Agent 的调试比纯文本复杂得多。我的经验是先把每个模态单独调通再做融合。不要一上来就搞全链路否则出问题很难定位。6. 一些个人体会与后续方向做 Agent 开发这一年多最大的感受是技术栈的复杂度在快速上升但核心方法论其实没变。多模态、Harness、MCP 这些新概念本质上都是在解决“如何让 Agent 更可靠地完成复杂任务”这个老问题。理解了这个本质就不会被各种新名词带偏。我目前重点在探索几个方向。一是多模态 Agent 的成本优化如何在保证效果的前提下降低 token 消耗。二是 Harness 的可观测性如何让 Agent 的决策过程可追溯、可调试。三是 MCP 生态的治理如何管理大量第三方工具的质量和安全性。这些方向都还在早期没有成熟方案。但正是这种不确定性让这个领域充满了机会。对于想入局的开发者我的建议是不要只盯着模型本身Harness 和工具生态的工程能力同样重要甚至更重要。模型能力会趋同但工程能力的差距会长期存在。