1. 项目概述当“少即是多”成为AI智能体的新范式最近在折腾大语言模型LLM应用开发的朋友可能都听过一个词Agentic。它不再是实验室里的概念而是正在成为构建下一代AI应用的核心架构思想。简单说它让LLM从一个被动的“答题器”变成了一个能主动规划、使用工具、与环境交互的“智能体”。但随之而来的问题也显而易见为了让智能体更“聪明”我们是不是得给它塞进更多的上下文、更复杂的指令、更庞大的知识库直觉告诉我们“是”但最新的研究和实践风向却指向了一个反直觉的结论——“更少甚至更少反而更好”。这个观点正是“Yet Even Less Is Even Better For Agentic, Reasoning, and Coding LLMs”这个标题所揭示的核心。它并非空穴来风而是源于对当前LLM应用特别是智能体、推理和代码生成场景下一系列痛点的深刻反思。我们常常陷入一个误区认为给模型的输入信息越多、越详细它就能做出越好的决策。于是我们精心构造冗长的系统提示System Prompt在上下文中堆叠大量的示例Few-Shot Examples甚至把整个项目文档都塞进去。结果呢模型的表现可能不升反降推理速度变慢成本飙升最关键的是输出的稳定性和可控性变得难以捉摸。这背后的原因与LLM的工作原理息息相关。过长的上下文会引入大量噪声分散模型的注意力使其难以抓住核心指令和关键约束。在需要多步推理Reasoning或复杂代码生成Coding的任务中这种干扰尤为致命。模型可能会在无关的细节上“钻牛角尖”或者因为上下文过长而“忘记”了最初的目标。因此一种新的设计哲学正在兴起通过极致的精简和结构化最大化LLM的核心能力。这不仅仅是提示工程Prompt Engineering的优化更涉及到智能体工作流设计、工具调用策略乃至模型服务架构的根本性变革。接下来我们就深入拆解如何在智能体、推理和编码这三个关键领域实践“少即是多”的原则。2. 核心设计思路从“信息轰炸”到“精准制导”为什么“少”反而能带来“多”的效果这需要我们从LLM的认知负载和任务分解两个层面来理解。传统的“信息轰炸”式提示好比给一个工程师同时下达十个模糊且相互关联的指令他很容易陷入混乱分不清主次。而“精准制导”则是先明确最终目标然后拆解出清晰、独立、可执行的原子步骤每一步只提供完成该步骤所必需的最少信息。2.1 智能体Agentic工作流的重构在构建AI智能体时我们习惯设计一个“超级提示”试图让单个LLM调用完成所有事情理解用户意图、规划步骤、选择工具、执行、总结。这导致了极其冗长且脆弱的提示词。新的思路是分层与解耦。第一层意图理解与任务规划器。这个模块的输入应该尽可能“少”——只有用户的原始请求。它的核心职责是进行高层次的抽象和分解输出一个结构化的任务列表或流程图而不是具体的执行细节。例如用户说“帮我分析一下上个月的销售数据并预测下个季度的趋势”。规划器不应该去接触具体的数据库字段或算法模型它只需要输出类似[“检索销售数据” “进行趋势分析” “生成预测报告”]这样的原子任务序列。这个规划器本身可以由一个专门优化过的、擅长分解任务的轻量级模型或精炼提示词来驱动。第二层原子任务执行器。每个原子任务对应一个高度专业化、输入极简的LLM调用。例如对于“检索销售数据”这个任务给执行器的提示可能仅仅是“工具数据库查询接口。查询目标获取过去30天的每日销售额和产品类别。返回格式JSON。” 这里没有任何关于“为什么”要查数据的冗余解释因为这是规划器已经决定的事情。执行器只关心“如何”完成这个具体动作。第三层结果合成器。将各个原子任务的结果汇总形成最终输出。合成器同样只需要最少的信息各个任务的输出结果以及最初的用户请求。它不需要再次回顾整个复杂的规划过程。这种架构的核心优势在于每个环节的LLM都处在“低认知负载”状态下只需处理有限、明确的信息从而大幅提高了单步决策的准确性和可靠性。整个系统的可维护性和可调试性也大大增强——如果预测报告不准你可以单独检查“生成预测报告”这个原子任务的输入输出而不必在长达数千token的混乱上下文中大海捞针。2.2 推理Reasoning过程的链式澄清对于复杂的数学、逻辑或多步骤推理问题一股脑地把问题和所有背景知识丢给模型往往会导致推理链的断裂或偏离。链式思维Chain-of-Thought的进阶玩法是“少步快跑持续澄清”。关键技巧分步追问而非一次性告知。不要试图在一个提示里让模型完成从问题到最终答案的所有推理。相反应该设计一个交互循环第一步给模型最精简的问题陈述要求它给出第一步的推理或第一个子问题。例如“问题一个水池有进水管和出水管...问多久能填满请只列出解决这个问题你需要知道的第一步是什么或者你首先会计算哪个量”第二步根据模型的回答例如“我需要知道进水管和出水管的单独工作效率。”提供恰好且仅够回答这一步的信息。例如“进水管单独工作4小时可注满出水管单独工作6小时可排空。”第三步要求模型基于新信息进行下一步推理或提出下一个需要澄清的点。如此循环直到最终得出答案。这种方法强制模型进行“在线”的、增量式的思考避免了在长上下文中迷失。它把复杂的推理任务拆解成了多个简单的“问答对”每个“问答对”的上下文都非常短小精悍。这对于处理那些需要多领域知识或存在模糊假设的推理问题特别有效。模型在每一步都只需要聚焦于当前最紧迫的小问题从而保证了推理路径的清晰和正确。2.3 代码生成Coding的上下文净化在辅助编程场景下我们总想给模型尽可能多的上下文整个文件的内容、相关的其他模块、项目规范文档等等。但这常常导致生成的代码偏离焦点或者引入了不必要的依赖。实践方案基于抽象接口和精准上下文的生成。核心思想是让模型基于“约定”和“签名”来编程而不是基于“实现细节”。函数级生成当需要模型补全一个函数时不要给它整个文件。只给它1该函数的签名函数名、参数、返回类型2清晰的功能描述注释3可能涉及的、最重要的1-2个外部API的调用方式仅签名而非其内部代码。屏蔽掉文件中的所有其他函数实现和无关的全局变量。这迫使模型只依赖最核心的契约信息进行创作生成的代码往往更简洁、更符合单一职责原则。模块间协作当需要生成调用其他模块的代码时提供被调用模块的接口文档摘要用自然语言描述输入输出和行为而不是其源代码。这模拟了真实开发中基于文档编程的方式避免了模型对他人代码内部复杂逻辑的过度拟合或误解。迭代式重构先生成一个极简的、仅满足核心功能的版本上下文极少。然后以这个版本为基础逐步添加需求如错误处理、日志、性能优化每次只围绕一个新增需求提供上下文。这比一次性要求生成一个“完美”的、包含所有特性的版本要可靠得多。注意这种“少即是多”的代码生成方式对项目本身的代码结构清晰度提出了更高要求。它倒逼开发者编写更模块化、接口定义更明确的代码这本身就是一个良性循环。3. 关键技术实现与工具选型要将上述思路落地离不开合适的技术栈和工具。这里我们重点分析两个方向一是服务于“精准上下文”的底层技术二是实现“智能体工作流”的框架或模式。3.1 上下文管理与检索增强生成RAG的精准化传统的RAG容易陷入“多即是好”的陷阱针对一个查询从向量库中检索出Top K个最相似的文档片段全部塞给LLM。这常常会引入无关信息。“少即是多”的RAG追求的是“精准检索”和“动态上下文”。混合检索与重排序Reranking不要完全依赖向量相似度。结合关键词检索如BM25进行初步筛选然后使用一个更精细的、专门训练过的重排序模型对候选片段进行二次评分只选出最相关、信息冗余度最低的1-2个片段送入LLM。重排序模型能更好地理解查询与片段之间的语义关联和答案支持度。句子级 vs. 段落级检索很多时候答案可能只隐藏在一段话的某一句里。尝试将文档拆解到句子级别进行索引和检索。虽然这会增加索引量但能极大提升上下文的精准度。对于代码库则可以拆解到函数或类级别。查询扩展与分解在检索前先用一个小模型对用户原始查询进行意图解析和分解。例如将“如何用Python连接MySQL并实现分页查询”分解为“Python MySQL连接库选择”、“建立数据库连接的基本代码”、“SQL分页查询语法”等多个子查询分别进行精准检索再将结果去重、合并后形成最终上下文。这比用一个复杂查询去匹配一堆文档要有效得多。工具参考像LlamaIndex这类框架已经提供了高级检索器如SentenceWindowNodeParser用于句子级检索、重排序后处理器以及查询引擎的链式组合功能可以方便地搭建这种精准化RAG流水线。3.2 智能体框架的设计模式从Monolithic到Modular当前热门的智能体框架如LangChain、AutoGen等提供了强大的构建能力但也容易让开发者写出庞大、复杂的“单体式”智能体。遵循“少即是多”我们应更倾向于微智能体Micro-agent或函数调用Function Calling模式。基于Function Calling的轻量级编排利用现代LLM原生支持的函数调用能力构建一个核心“路由器”智能体。这个路由器的系统提示非常精简只描述它有哪些可用的工具函数以及每个工具的纯粹功能描述。用户请求到来时路由器分析意图决定调用哪个工具或工具序列并将用户输入转化为严格的工具参数。每个工具背后都是一个独立的、功能单一的模块可能是一段代码、一个API调用或一个简单的子提示词。这种模式下LLM路由器的上下文始终很干净复杂的逻辑被下放到了具体的工具实现中。状态机与工作流引擎对于有严格步骤的任务直接用LLM来做流程控制并不稳定。更好的方法是使用外部的状态机或工作流引擎如Airflow、Prefect或更轻量的如状态模式代码来定义步骤流程。LLM只作为每个步骤中的“决策大脑”或“内容生成器”被调用。这样每个LLM调用的上下文都只包含当前步骤的状态和输入完全隔离了其他步骤的复杂性。“STITCH”理念的启发虽然无法获取其具体细节但“STITCH”这个概念很可能指向一种将小型、专一的组件智能体或模块“缝合”在一起以完成复杂任务的架构。这与我们的“微智能体”思路不谋而合。每个组件Stitch只做一件事并定义清晰的输入输出接口。一个顶层的、轻量的协调器负责按照某种逻辑可能是预定义的也可能是动态规划的将这些组件串联起来。这种架构的调试、更新和扩展成本都远低于一个巨无霸智能体。4. 实操演练构建一个“少即是多”的代码助手智能体让我们通过一个具体场景来实践上述理念构建一个代码助手智能体它能根据用户自然语言描述在一个已有项目中创建或修改Python文件。传统低效做法系统提示长达数百行包含项目结构介绍、编码规范、所有依赖库的说明、各种工具的使用方法等等。用户请求“在utils目录下创建一个新的日志工具类。” LLM需要从海量上下文中找到utils目录的位置、理解项目现有的日志格式、回忆编码规范然后一次性生成一个完整的类。这个过程容易出错且难以定位问题根源。“少即是多”做法我们设计一个由三个微智能体或函数组成的流水线4.1 智能体A需求解析与任务规划器系统提示极简“你是一个任务分解器。用户会提出一个代码相关的需求。你需要将其分解为1到4个清晰的、可顺序执行的原子任务。每个原子任务必须是具体的操作例如‘创建文件’‘修改函数’‘添加导入语句’等。输出格式为严格的JSON列表[{action: “动作名” “target”: “目标描述” “detail”: “额外细节”}]。不要生成任何代码。”用户输入“在utils目录下创建一个新的日志工具类要求使用structlog库并包含debug, info, error三个级别的方法类名AppLogger。”智能体A输出[ {action: inspect_project_structure, target: 确认utils目录是否存在及路径, detail: }, {action: create_file, target: utils/logger.py, detail: 创建文件内容为AppLogger类的骨架}, {action: review_and_add_dependency, target: 检查并添加structlog到项目依赖文件, detail: 如pyproject.toml或requirements.txt} ]4.2 智能体B原子任务执行器以“create_file”为例系统提示极简“你是一个代码生成器。根据给定的任务描述生成Python代码。你只关心当前这个文件的内容不要考虑项目其他部分。确保代码语法正确、符合PEP8基本规范。”上下文精准任务{action: create_file, target: utils/logger.py, detail: 创建文件内容为AppLogger类的骨架}用户原始需求摘要仅一行“一个使用structlog的日志类AppLogger含debug, info, error方法。”可选从项目根目录实时检索到的、仅关于structlog用法的1-2个示例代码片段通过精准RAG获得。智能体B输出utils/logger.py的初始内容import structlog class AppLogger: def __init__(self, name: str __name__): self._logger structlog.get_logger(name) def debug(self, message: str, **kwargs): self._logger.debug(message, **kwargs) def info(self, message: str, **kwargs): self._logger.info(message, **kwargs) def error(self, message: str, **kwargs): self._logger.error(message, **kwargs)4.3 智能体C上下文感知的代码审查与增强器触发条件当文件创建或修改后自动触发。系统提示极简“你是一个代码审查员。对比新生成的代码片段和项目中已有的相关代码风格例如导入惯例、异常处理模式、配置加载方式。如果发现明显的不一致或可以改进以更符合项目习惯的地方提出具体的修改建议。输出格式{“suggestions”: [“建议1”, “建议2”]}”上下文精准新生成的代码utils/logger.py的内容。从项目中检索到的、其他utils目录下工具类的代码风格示例例如它们如何做单例模式、如何读取配置。智能体C输出{ suggestions: [ 项目中其他工具类通常有一个get_instance()类方法来实现单例建议为AppLogger添加。, 建议从config.settings中读取日志级别而不是硬编码。 ]然后可以将这些建议反馈给用户确认或由另一个简单的自动合并规则来处理。整个过程中每个LLM调用都目的明确、上下文干净大大降低了幻觉和错误的概率也使得每一步都可以独立验证和优化。5. 性能优化与成本控制实战“少即是多”的理念直接带来了显著的性能和成本优势。我们来量化分析一下。5.1 延迟与吞吐量的提升LLM API的调用延迟Latency通常与输入/输出令牌数正相关。假设一个复杂的单体智能体提示需要8000个输入token而我们的微智能体流水线中每个步骤平均只需1500个输入token。单体模式单次调用处理8000 token假设延迟为T_mono。流水线模式三次调用每次1500 token。虽然调用次数增多但现代API服务特别是类似chimera这类关注多模型、低延迟服务的理念所倡导的对于短上下文的处理速度极快。假设每次短调用延迟为T_micro通常T_microT_mono。对比即使3 * T_micro略大于T_mono但流水线模式的感知延迟可能更低因为用户可以更快地看到第一个规划结果智能体A的输出获得了即时反馈。而从系统吞吐量看短上下文请求更容易被API服务端批量处理整体资源利用率更高系统能同时处理更多并发请求。5.2 Token消耗与成本的下降这是最直接的收益。以GPT-4为例其输入token成本远高于输出token。假设场景完成一个任务单体提示消耗8000输入token输出2000 token。微智能体流水线规划器消耗500输入100输出执行器消耗1500输入800输出审查器消耗1000输入300输出。总计输入3000 token输出1200 token。成本节省仅输入token就节省了5000个。按照GPT-4的定价这意味著单次请求成本可能降低超过60%。对于高频应用这种节省是巨大的。5.3 缓存策略的优化空间精简、结构化的上下文使得缓存Caching更加高效。结果缓存原子任务如“根据函数签名生成一个获取用户信息的函数”的输入输出非常稳定极易缓存。相同的任务输入可以直接返回缓存的结果无需调用LLM。嵌入缓存在RAG中对精简后的查询如分解后的子查询进行向量化并缓存比缓存原始复杂查询的向量更有意义命中率更高。规划缓存对于常见的用户请求模式如“帮我写一个CRUD API”其任务规划结果[“生成模型” “生成序列化器” “生成视图” “生成路由”]是可以被缓存和复用的。通过实施这些缓存策略可以进一步将实际调用LLM的次数和token消耗压到最低实现成本和延迟的双重优化。6. 常见陷阱与避坑指南在实践“少即是多”的过程中我也踩过不少坑。这里分享一些关键的注意事项和排查技巧。6.1 规划器过于抽象或过于具体问题规划器智能体A分解的任务要么太抽象如“实现功能”导致执行器无法操作要么太具体直接写出了代码片段失去了分解的意义且使执行器上下文冗余。排查与解决为规划器提供明确的输出格式约束和示例。在系统提示中给出2-3个好的和坏的分解例子。引入验证环节。设计一个简单的规则校验器可以是正则表达式或小模型检查规划器输出的任务列表是否满足“原子性”和“可执行性”。例如检查每个“action”是否在预定义的可执行动作集合中。迭代优化。收集一批失败案例分析是规划问题还是执行问题。如果是规划问题针对性调整规划器的提示词。6.2 原子任务间的状态传递丢失问题任务B依赖于任务A的输出结果。如果只是机械地执行任务B的LLM可能不知道任务A产生了什么。解决设计一个共享的、结构化的状态存储如一个JSON对象或数据库中的记录。每个任务执行完毕后必须将其关键产出物写入这个状态存储。下一个任务在执行前其上下文会自动包含从状态存储中提取的、它所需的前置任务结果。要确保传递的是精简的、必要的结果摘要而不是原始的大段输出。6.3 错误处理与回滚变得复杂问题流水线中一个环节失败如何优雅地处理整个流程是重试还是部分回滚解决为每个原子任务设计幂等性。确保任务可以安全地重试。例如“创建文件”任务在执行前先检查文件是否存在且内容是否符合预期。实现工作流引擎。使用如Prefect、Airflow或甚至一个简单的状态机库来管理流程。它们内置了重试、超时、依赖管理和错误处理机制。定义清晰的失败语义。每个任务都应定义几种明确的失败状态如“输入无效”、“依赖缺失”、“执行超时”并由上游协调器根据不同的失败类型决定下一步动作如重试、跳过、或整体失败。6.4 对现有项目结构的依赖问题“少即是多”的代码生成高度依赖清晰的项目结构和文档。如果项目本身混乱不堪精准检索和接口抽象将无从谈起。解决这实际上是一个推动代码规范化的契机。可以考虑分两步走先辅助后智能。初期先使用智能体完成一些对结构依赖较低的任务如代码注释生成、单函数重构、单元测试生成等。引入“项目分析”前置任务。在执行用户需求前先运行一个智能体来分析项目的主要目录结构、依赖关系和接口模式生成一份临时的“项目上下文摘要”。后续的所有精准检索和生成都基于这份摘要进行而不是直接面对混乱的源码。这相当于为混乱的项目临时建立了一个清晰的“地图”。7. 未来展望与进阶思考“少即是多”不是一个静态的规则而是一个动态优化的方向。随着LLM本身能力的演进和基础设施的完善这个理念会有更深入的实践。模型本身的进化未来可能会出现更擅长“规划”和“工具使用”的专用模型它们能在极短的上下文内精准理解任务并分解出最优步骤。或者模型对长上下文的处理能力质变能够真正实现“大海捞针”那时“多”可能重新具备优势。但在此之前结构化、精简化的策略依然是性价比最高的选择。工具生态的标准化如果智能体工具函数的接口描述能够高度标准化例如采用统一的OpenAPI规范并附带高质量的自然语言描述那么规划器和执行器之间的协作将更加顺畅“少上下文”的效益会进一步放大。这需要社区在工具开发时就考虑到与AI智能体的协作。人机协作界面的重新设计当智能体以流水线、分步骤的方式工作时用户界面也应该与之匹配。不再是输入一个请求后等待一个“黑箱”给出最终答案而是可以展示任务规划图、实时看到每个原子任务的执行状态和中间结果、并在关键决策点进行干预或确认。这种透明化和可控性是“少即是多”架构带来的额外红利能极大提升用户信任和体验。从我个人的实践来看拥抱“少即是多”更像是一次思维模式的转变。它要求我们从追求“功能强大的单体”转向设计“协作精良的乐团”。每个乐手微智能体只需精通自己的乐器原子任务在指挥协调逻辑的调度下就能演奏出复杂的乐章。这个过程初期需要更多的设计工作但带来的稳定性、可维护性和成本效益的提升无疑是值得的。尤其是在面对智能体、复杂推理和代码生成这些高挑战性场景时化繁为简聚焦核心往往才是通往更优解的那条路。