大模型的能力边界到底在哪，这个问题在过去一年里被问烂了。但真正动手做过落地的人会发现，官方文档里列的那些能力清单，和实际项目里能稳定跑通的能力，中间隔着一整条鸿沟。我前后参与过几个大模型相关的项目，从最开始的提示词调优，到后来的Agent编排、本地部署、微调实验，踩过的坑比想象中多得多。这篇内容想做的事情很直接：把大模型的能力版图拆开来看，哪些是真正能用的，哪些是看起来很美但落地困难的，以及每一块能力背后需要什么配套工具和工程手段。不管你是刚接触大模型想搞清楚全貌，还是已经在做Agent开发想补齐认知盲区，这篇内容应该都能给你一些参考。
1. 大模型能力版图的六个真实分层
很多人理解大模型能力的方式是看榜单，MMLU多少分、HumanEval多少分、数学竞赛题能做对几道。但榜单分数和实际可用性之间的关系，远比想象中弱。我倾向于把大模型的能力分成六个层次来看，从最基础的文本生成到最复杂的自主Agent，每一层对模型的要求、对工程配套的要求、以及落地的难度都完全不同。
1.1 文本生成与理解：最成熟但也最容易被低估
文本生成和理解是所有大模型能力的底座。看起来简单，但真正做好并不容易。这里说的不是"让模型写一段话"这种程度，而是指在特定格式约束下、在特定知识范围内、以特定风格输出稳定可控的文本。
实际项目中最常见的需求包括：结构化信息抽取（从合同、简历、工单里提取字段）、文本分类与路由（判断用户意图走哪条处理链路）、内容改写与摘要（把长文档压缩成指定长度的摘要）。这些任务听起来平平无奇，但它们是整个系统里调用量最大的部分。
我做过一个工单自动分类的项目，表面上是"文本分类"这么简单的事，但实际落地时遇到的问题包括：类别边界模糊导致模型摇摆、长尾类别样本极少导致召回率低、用户输入包含大量错别字和口语化表达导致理解偏差。解决这些问题靠的不是换更大的模型，而是精心设计的提示词模板加上few-shot示例的选取策略。
这里有一个经验：对于文本理解和生成类任务，提示词工程（Prompt Engineering）的投入产出比远高于模型升级。我试过同一个抽取任务，用中等规模的模型配合精心设计的提示词，效果比用最大模型配随便写的提示词要好得多。关键在于把任务拆解清楚、把输出格式约束死、把边界情况用示例覆盖到。
1.2 代码生成与工具调用：从"能写"到"能用"的距离
代码生成是大模型能力中被讨论最多的之一，也是实际落地效果分化最大的。模型能写出一段看起来正确的代码，和这段代码能在你的项目里直接跑通，是两件完全不同的事。
我自己的体验是：对于算法题级别的代码，现在的主流大模型基本都能写对；对于框架级别的代码（比如写一个React组件、写一个FastAPI接口），模型能给出可用的骨架但细节经常出错；对于涉及具体业务逻辑和内部API的代码，模型基本只能起到辅助作用，需要大量人工修正。
工具调用（Tool Use / Function Calling）是另一个维度。模型能不能正确理解什么时候该调用什么工具、参数怎么填、返回值怎么处理，这直接决定了Agent系统能不能跑起来。实际测试下来，工具调用的可靠性受几个因素影响很大：工具描述的质量、参数schema的清晰度、以及模型对多轮工具调用链的规划能力。
一个容易忽略的细节：工具描述不要写得太"官方"，要用模型能理解的自然语言描述这个工具做什么、什么时候用、输入输出是什么。我见过太多项目把OpenAPI的schema直接丢给模型，效果很差。
1.3 多模态理解：图片、文档、表格的处理能力
多模态大模型这两年进步很快，但实际可用的场景和宣传的能力之间还是有差距。目前比较稳定的多模态能力包括：图片内容描述、简单图表理解、文档OCR后的信息抽取、表格结构识别。
不太稳定的包括：复杂图表中的精确数值读取、多图之间的逻辑推理、视频内容的时序理解。我在一个票据识别项目里用过某多模态模型做发票信息抽取，简单发票没问题，但遇到盖章遮挡、手写体、多联票据的情况，准确率就明显下降。
多模态能力的使用有一个关键决策：是让多模态模型直接处理原始图片，还是先用OCR/文档解析工具提取文本再交给语言模型处理。我的经验是，对于结构化程度高的文档（比如标准合同、规范表格），先用专业工具解析再交给语言模型，效果更稳定；对于非结构化或版式复杂的材料，多模态模型直接处理更有优势。
1.4 推理与规划：慢思考能力的实际价值
推理能力是大模型能力版图里最被高估也最被低估的部分。被高估是因为榜单上那些数学竞赛题的成绩容易让人产生"模型真的会推理"的错觉；被低估是因为在合适的场景下，推理能力确实能解决传统方法搞不定的问题。
实际项目中，推理能力真正有价值的场景是：多步骤的业务规则判断、需要权衡多个约束条件的决策、以及复杂问题的分解与规划。比如在一个报销审核场景里，模型需要同时考虑报销政策、金额阈值、历史记录、异常模式等多个因素，这种任务用规则引擎写会非常复杂且难以维护，用大模型的推理能力反而更灵活。
但要注意，推理能力对延迟和成本的影响很大。让模型"一步一步想"确实能提升准确率，但token消耗可能翻好几倍。在实际系统里，我通常会用路由策略：简单请求走快速通道，复杂请求才触发深度推理。
1.5 Agent与自主执行：能力版图的最前沿
Agent是大模型能力版图里最热但也最不成熟的部分。核心思路是让模型不只是回答问题，而是能自主规划步骤、调用工具、执行操作、根据反馈调整策略。
目前Agent能稳定跑通的场景其实比较有限：信息检索与汇总、简单的流程自动化、代码辅助生成与调试。而在需要长链条规划、需要处理大量异常情况、需要与复杂系统交互的场景里，Agent的可靠性还远远不够。
Agent开发中最核心的工程问题不是模型能力，而是Harness的设计。Harness这个词在Agent语境下指的是包裹在模型外面的那层工程框架，负责管理上下文、调度工具、处理错误、控制循环。一个好的Harness能让中等能力的模型表现出色，一个差的Harness能让最强模型频繁翻车。
1.6 微调与定制化：让通用能力适配垂直场景
微调是大模型能力版图里最"重"的一块。它解决的核心问题是：通用模型在特定领域的表现不够好，而提示词工程又无法弥补这个差距。
微调真正有效的场景包括：特定领域的术语理解（医疗、法律、金融）、特定格式的输出（企业内部的结构化报告）、特定风格的生成（品牌调性统一的文案）。而微调效果不明显的场景包括：需要广泛世界知识的任务、需要复杂推理的任务、数据量不足的场景。
我做过一次垂直领域的微调实验，用几千条高质量的业务数据对一个中等规模的开源模型做LoRA微调。结果是：在领域术语理解和格式遵循上确实有明显提升，但在通用推理能力上反而有所下降。这提醒我们，微调不是万能药，它是在做能力的重新分配，而不是全面提升。
2. Benchmark与Harness：能力评估背后的工程真相
聊大模型能力，绕不开两个词：Benchmark和Harness。前者是衡量能力的标尺，后者是让能力落地的框架。这两个词在实际项目里的重要性，远比大多数人意识到的要高。
2.1 Benchmark到底测的是什么
Benchmark本质上是一组标准化的测试题加上一套评分规则。常见的Benchmark包括MMLU（综合知识）、HumanEval（代码生成）、GSM8K（数学推理）、MT-Bench（对话质量）等。
但Benchmark分数和实际可用性之间的鸿沟来自几个方面。第一，Benchmark的题目分布和你的实际业务分布往往差异巨大。一个在MMLU上拿高分的模型，在你的垂直场景里可能表现平平。第二，Benchmark通常测的是单轮、独立的任务，而实际应用是多轮、有上下文、有工具调用的复杂流程。第三，Benchmark的评分规则往往是自动化的，可能无法捕捉到实际使用中重要的质量维度。
我的建议是：Benchmark分数用来做初筛，不要用来做最终决策。真正靠谱的评估方式是构建自己的业务评测集，用真实场景的数据和真实的评估标准来衡量。
2.2 自建评测集的实操方法
构建自己的评测集，听起来工程量大，但实际做起来可以很轻量。我的做法是：
- 从真实业务日志里采样200-500条请求，覆盖主要场景和边界情况
- 为每条请求标注期望的输出（可以是人工标注，也可以是从历史成功案例里提取）
- 定义评分标准：完全正确、部分正确、错误、有害，四个等级
- 用脚本批量跑评测，输出每个模型的得分分布
这个评测集不需要很大，但一定要真实。我见过太多团队用公开Benchmark选模型，上线后才发现效果不达预期。而一个几百条真实数据的评测集，能在选型阶段就避免大量返工。
2.3 Harness：被低估的工程核心
Harness这个词在Agent和模型部署语境下，指的是包裹在模型外面的工程框架。它负责的事情包括：上下文管理（决定哪些信息放进prompt）、工具调度（决定什么时候调用什么工具）、错误处理（模型输出异常时怎么兜底）、循环控制（Agent执行多少步后强制停止）。
Harness的设计质量直接决定了系统的可靠性。同一个模型，配一个好的Harness和配一个差的Harness，表现可能天差地别。我见过一个案例：团队抱怨模型工具调用总是出错，排查后发现是Harness在拼接工具返回值时格式有问题，导致模型理解不了上一步的执行结果。
一个实用的经验：Harness的日志要尽可能详细。每次模型调用时的完整prompt、模型的原始输出、工具调用的参数和返回值、最终给用户的响应，这些都要记录下来。出问题时，这些日志是排查的唯一依据。
2.4 Harness和Agent的区别与联系
很多人搞不清楚Harness和Agent的区别。简单来说，Agent是一种能力形态（模型自主规划、调用工具、执行任务），Harness是实现这种能力形态的工程框架。Agent是概念，Harness是落地。
一个完整的Agent系统通常包含：模型（负责推理和决策）、Harness（负责调度和管理）、工具集（负责具体执行）、记忆系统（负责状态保持）。Harness是连接模型和工具的中间层，它的设计决定了Agent能做什么、不能做什么、以及做得多可靠。
在实际开发中，我倾向于把Harness设计得尽量简单和确定。模型负责它擅长的部分（理解意图、生成内容、做判断），Harness负责它擅长的部分（状态管理、错误重试、格式校验、流程控制）。不要让模型去做它不擅长的事，比如精确的数值计算、严格的状态跟踪。
3. Agent开发中那些文档不会告诉你的坑
Agent开发是当前大模型落地最热的方向，但也是最容易踩坑的方向。官方文档和教程通常展示的是理想情况下的流程，而实际开发中遇到的问题往往完全不同。
3.1 并发问题：Agent系统扛不住高并发怎么办
AI Agent怎么扛并发，这是很多团队从Demo走向生产时遇到的第一个大问题。Agent的每次执行可能涉及多次模型调用和工具调用，单次请求的延迟可能是几秒到几十秒，这导致单实例能支撑的并发量非常有限。
解决并发问题的思路有几个层次。第一层是异步化：把Agent的执行流程改成异步的，不要让请求线程阻塞等待。第二层是队列化：用消息队列缓冲请求，后端按自己的能力消费。第三层是缓存：对于重复或相似的请求，缓存中间结果或最终结果。第四层是降级：在高负载时，自动切换到更轻量的处理路径。
我实际做过的一个方案是：用异步任务队列处理Agent请求，前端提交后返回任务ID，客户端轮询或通过WebSocket获取结果。同时在Harness层做了请求去重和结果缓存，对于相同输入的请求直接返回缓存结果。这套方案把系统的吞吐量提升了一个数量级。
3.2 上下文管理：token限制下的信息取舍
Agent执行过程中，上下文会不断增长：系统提示词、历史对话、工具调用记录、工具返回结果。很快上下文就会超出模型的token限制，这时候就需要做信息取舍。
常见的策略包括：滑动窗口（只保留最近N轮）、摘要压缩（把早期对话压缩成摘要）、重要性筛选（只保留与当前任务相关的信息）。每种策略都有代价：滑动窗口可能丢失关键信息，摘要压缩可能引入误差，重要性筛选需要额外的判断逻辑。
我的经验是：对于工具调用密集的Agent，工具返回结果的处理最关键。不要把工具的原始返回全部塞进上下文，而是提取关键字段、做结构化压缩。比如一个搜索工具返回了10条结果，不需要把10条全部放进上下文，提取最相关的3条加上摘要就够了。
3.3 错误处理：模型输出不符合预期时的兜底策略
Agent系统里，模型输出不符合预期是常态而不是异常。可能的情况包括：输出了无效的JSON、调用了不存在的工具、参数格式错误、陷入了循环。
Harness层需要对这些情况做系统性的处理。我的做法是分三级：第一级是格式校验和自动修复（比如JSON解析失败时尝试修复常见格式问题），第二级是重试（带上错误信息让模型重新生成），第三级是降级（切换到预设的兜底响应或转人工）。
关键是要设置合理的重试上限和超时时间。我见过一个Agent因为工具调用一直失败又一直重试，导致单次请求跑了十几分钟还没结束。后来加了硬性限制：单次请求最多调用工具10次，总执行时间不超过60秒，超过就强制返回当前结果。
3.4 工具设计的艺术：让模型用得顺手
工具设计是Agent开发中最被低估的环节。一个好的工具设计能让模型调用准确率大幅提升，一个差的工具设计会让模型频繁出错。
工具设计的核心原则是：描述要清晰、参数要简单、返回值要结构化。具体来说：
- 工具名称要语义明确，不要用缩写或内部代号
- 工具描述要说明"什么时候用这个工具"，而不只是"这个工具做什么"
- 参数尽量少，必填参数尽量简单，复杂参数提供默认值
- 返回值用结构化格式（JSON），包含明确的成功/失败标识和错误信息
我做过一个对比实验：同一个搜索功能，一个版本的工具描述写得很技术化（"执行向量检索，返回top-k结果"），另一个版本写得很自然（"当需要查找相关信息时使用这个工具，输入你的问题，返回相关的文档片段"）。后者的调用准确率明显更高。
4. 开源生态与本地部署的现实考量
开源大模型和本地部署是很多团队关心的话题。动机通常包括：数据安全、成本控制、定制化需求。但实际落地时，需要权衡的因素比想象中多。
4.1 开源模型选型：不只看参数规模
开源模型的选择不能只看参数规模。一个7B的模型在特定任务上可能比70B的模型表现更好，如果前者经过了针对性的微调。选型时需要考虑的维度包括：基础能力（理解、生成、推理）、领域适配度、推理成本、部署难度、社区活跃度。
我自己的选型流程是：先明确任务需求（需要什么能力、什么延迟要求、什么成本约束），然后筛选出3-5个候选模型，用自建评测集跑一轮，最后选综合表现最好的。不要迷信榜单，也不要迷信参数规模。
4.2 本地部署的硬件与成本账
本地部署大模型的成本不只是硬件采购，还包括运维、电力、以及机会成本。我算过一笔账：部署一个中等规模的开源模型，需要一张显存足够的GPU，加上配套的服务器、网络、存储，初期投入不小。如果只是低频使用，用API的成本可能更低。
本地部署真正划算的场景是：调用量非常大（API费用超过自建成本）、数据不能出内网、或者需要深度定制化。如果只是"想试试"，建议先用API，等需求明确了再考虑本地部署。
4.3 微调实战：数据质量比数据数量重要
大模型微调实战中，最常见的误区是追求数据量。实际上，对于大多数垂直场景，几百到几千条高质量数据就能看到明显效果，关键是数据质量。
高质量微调数据的标准是：输入输出格式统一、覆盖主要场景和边界情况、输出内容准确且风格一致。我做过一次对比：用5000条低质量数据（格式不统一、有噪声）微调，效果不如用800条精心清洗和标注的数据。
微调的另一个关键是评估。微调后一定要在保留集上评估，确认没有过拟合，同时要评估通用能力是否下降。我通常会在微调数据里混入一定比例的通用数据，缓解灾难性遗忘的问题。
5. 从能力版图到落地路线：我的实操建议
把大模型的能力版图看清楚之后，落地路线其实就清晰了。我的建议是按能力成熟度从高到低推进，先做确定性高的，再做探索性的。
5.1 优先级排序：先做文本理解和生成
如果你的团队刚开始接触大模型，建议从文本理解和生成类任务入手。这类任务技术成熟度高、落地周期短、效果容易验证。具体可以从这些场景开始：文档信息抽取、用户意图分类、内容摘要生成、客服话术辅助。
这些场景的共同特点是：输入输出明确、评估标准清晰、对实时性要求不高。做好这些场景，团队能积累提示词工程、评测体系、Harness设计的基础经验，为后续更复杂的场景打基础。
5.2 逐步引入工具调用和Agent能力
有了文本处理的基础后，可以逐步引入工具调用能力。从最简单的单工具调用开始（比如让模型调用一个搜索接口），逐步过渡到多工具编排，最后再到完整的Agent流程。
这个过程中，Harness的设计能力是关键。建议从一开始就把Harness的日志、错误处理、重试机制做扎实，不要等到出问题了再补。我见过太多团队在Demo阶段跑得很顺，一上生产就各种问题，根源都是Harness层太薄弱。
5.3 微调和本地部署的时机判断
微调和本地部署不要过早启动。我的判断标准是：当提示词工程和Harness优化都已经做到位，但效果仍然不满足业务要求时，才考虑微调；当API调用成本超过自建成本，或者数据合规要求必须本地化时，才考虑本地部署。
这两个方向都需要不小的投入，过早启动容易浪费资源。而且，随着基础模型能力的持续提升，很多现在需要微调才能解决的问题，未来可能通过提示词就能解决。
5.4 团队能力建设：需要什么样的人
大模型落地需要的团队能力，和传统软件开发有明显差异。除了常规的工程能力，还需要：提示词设计与优化能力、评测体系构建能力、Harness开发能力、以及对模型行为边界的理解。
我的经验是，提示词工程和评测体系这两块，最好由对业务理解深的人来做，而不是纯技术人员。因为提示词的本质是把业务逻辑翻译成模型能理解的语言，评测的本质是定义什么是"好"的输出，这两件事都需要深厚的业务理解。
大模型的能力版图还在快速变化，今天不成熟的能力明天可能就成熟了，今天的最佳实践明天可能就过时了。保持对新技术和新方法的敏感度，同时把工程基础打扎实，是在这个领域持续做出成果的关键。我在实际项目中最深的体会是：不要追热点，要追问题。把业务问题定义清楚，把工程链路做扎实，模型能力自然会为你所用。
