“加一个Agent就解决问题”——这句口号正在拖垮无数团队2024年某个创业团队发布了一款写作类Agent产品。当时为了弥补大模型的缺陷他们做了大量的工程化工作——复杂的编排逻辑、精细的Prompt工程、多Agent协作框架。产品上线后效果不错团队士气高涨。2025年GPT-4.5发布原生能力覆盖了他们花了大半年搭建的工程架构。一夜之间那套复杂的编排系统从“核心竞争力”变成了“技术负债”。模型每进一步他们的工程价值就贬值一块。更讽刺的是另一组数据MIT 2025年的一项研究显示高达95%的企业AI项目达不到预期93%的Agent项目卡在POC到生产的跨越上。Google DeepMind与Google Research联合发布的论文则揭示了一个更残酷的规律当单Agent的准确率超过45%时增加Agent数量通常会带来负收益。我们正在经历一个被严重低估的拐点Agent系统的工程复杂度正在超越模型能力提升带来的边际收益。这让我想起查尔斯·汉迪的“第二曲线”理论——任何增长曲线都会在某个点触达顶峰然后开始衰退。真正的赢家是在第一曲线仍在上升时就开始布局第二曲线的人。对于Agent系统开发者来说第一曲线是“追逐模型能力”——模型越强系统越智能。但当工程复杂度的增长速度超过模型能力的提升速度时这条曲线正在逼近它的顶点。第二曲线是从“追逐模型”转向“驾驭工程”。一、第一曲线正在放缓模型能力提升的边际收益在递减1.1 模型很强但已经不够“更强”了2025年一个明显的变化是模型依然处在技术演进的中心位置但讨论重点已经发生了迁移。模型能力仍在提升但其边际影响开始放缓推理效率、成本结构、系统稳定性的重要性持续上升。这话什么意思GPT-4到GPT-4.5的提升远不如GPT-3.5到GPT-4的提升大。模型的“智力”在逼近天花板但每一次版本升级带来的工程适配成本却没有减少——新的输出格式、新的工具调用规范、新的行为模式都需要重新验证、重新调试。1.2 “多Agent越多越好”是一个被数据打脸的假设Google DeepMind的180组对照实验给出了一个清晰的结论Agent存在边际收益递减。当单个Agent的准确率超过45%时增加Agent数量不仅没用甚至是负收益。一个5个Agent串行的pipeline假设每个Agent的准确率是90%整体准确率只有0.9^559%。错误在传播中指数级放大。更糟糕的是任务越复杂Agent越多死得越快。当任务需要16种以上工具时多Agent系统会出现明显的“协调崩盘”——沟通、同步、解释彼此操作的成本会吞掉核心推理能力。1.3 “堆Token”策略也在失效业内一度流行两条“铁律”第一单个Agent能力有限多Agent协作就能解决复杂问题第二预算不够就多给点Token和工具调用次数性能自然会提升。但真实的案例正在推翻这个假设。一个Agent在24小时内消耗了3.2亿Token、执行了1129次工具调用暴露了高推理成本与低操作效率的矛盾。Token堆得再多如果系统本身没有正确的工程架构来承载这些Token只是在“烧钱”不是在“解决问题”。二、工程复杂度正在失控你的“解决方案”正在变成问题2.1 复杂度从未消失只是被推迟了“现在做Agent很简单用LangChain搭一搭就能跑。”这句话听起来很有道理但它掩盖了一个真相复杂性被平台吸收了但没有被消除。框架帮你拼接Prompt、裁剪Context让开发者远离细节。但调试、Trace、状态恢复这些底层骨架仍然无人替你承担。当Agent规模扩大Memory的一致性与状态清理反而成了新的系统复杂度。能跑起来并不等于能长期跑得对。所谓简单其实是我们暂时不用面对复杂。2.2 一个Agent是功能五十个Agent是分布式系统问题“一个AI Agent是个功能五十个Agent是个分布式系统问题——但没人讨论后者。”多Agent系统的核心问题从“这个Agent够不够聪明”变成了“分布式系统的一致性、调度、状态同步和故障恢复”。这些问题和你熟悉的微服务架构本质上是同一类问题但LLM调用的非确定性让每个环节的调试成本都翻了几倍。LangGraph就是一个典型。开发阶段它的优势非常明显——检查点、时间旅行调试、Human-in-the-Loop节点这些都是开箱即用的能力。但当你试图把它部署为一个服务化的产品时问题逐一暴露并发控制缺失、审计盲区、多租户隔离、资源配额、模型热切换。“能跑”和“能管”之间的距离比“能写代码”和“能写生产级代码”之间的距离还要远。2.3 过度工程化的致命陷阱更可怕的是过度工程化。代码智能体Coding Agents可以连续数小时参与软件项目开发但它们有时反而会增加软件项目的复杂度而并没有简化流程。你花三个月搭建的复杂编排系统可能在下一个大模型版本发布后就被模型新增的原生能力直接覆盖。应用层尚未形成稳定范式底层基础设施却已经需要提前面对并发增长、长上下文、缓存复用、推理延迟和服务可靠性等一系列问题。你在为一个还不存在的未来支付着今天的工程成本。三、第二曲线从“追逐模型”到“驾驭工程”3.1 第二曲线是什么亚马逊云科技将Agentic工程体系定义为把模型能力转化为可稳定交付业务结果的智能体的系统化工程能力。它不是单一技术点而是一套围绕模型、上下文、工具、流程、评估和治理构建起来的综合工程框架。这个体系正在从三个层次演进Prompt Engineering让模型理解“要做什么”Context Engineering让模型掌握“需要知道什么”Harness Engineering让模型能可靠地“把事情做完”第二曲线的核心就是Harness Engineering——围绕模型搭建稳定执行框架包括智能体循环、工具调用、任务评估、失败重试和安全护栏等机制。3.2 具体怎么做控制平面与执行平面分离当你有100个Agent同时运行时“能跑”和“能管”之间的鸿沟必须靠架构来填补。控制平面与执行平面分离是生产级Agent系统的核心原则。控制平面的职责是决定什么运行、怎么运行、运行得对不对。它不负责具体执行但所有执行都要经过它的许可和监控。# 控制平面的核心抽象调度、权限、审计fromdataclassesimportdataclassfromtypingimportOptional,ListfromenumimportEnumimportuuidimporttimeclassTaskStatus(Enum):PENDINGpendingRUNNINGrunningCOMPLETEDcompletedFAILEDfailedSUSPENDEDsuspendeddataclassclassAgentTask:控制平面管理的任务单元task_id:strtenant_id:stragent_type:strinput:dictstatus:TaskStatus created_at:floatpriority:intmax_tokens:intmax_steps:intassigned_worker:Optional[str]NoneclassControlPlane:控制平面调度、权限、审计def__init__(self):self.task_queue[]self.running_tasks{}self.audit_log[]self.quota_managerQuotaManager()self.policy_enginePolicyEngine()defsubmit_task(self,task:AgentTask)-str:提交任务先过策略引擎# 1. 权限检查租户是否有权运行这类Agentifnotself.policy_engine.check_permission(task.tenant_id,task.agent_type):raisePermissionError(fTenant{task.tenant_id}not authorized)# 2. 配额检查该租户是否还有配额ifnotself.quota_manager.check_quota(task.tenant_id):raiseQuotaExceededError(fQuota exceeded for tenant{task.tenant_id})# 3. 入队调度task.task_idstr(uuid.uuid4())task.created_attime.time()self.task_queue.append(task)self._audit(task_submitted,task)returntask.task_iddefschedule_next(self)-Optional[AgentTask]:调度器从队列中选取下一个可执行任务# 按优先级和创建时间排序self.task_queue.sort(keylambdat:(-t.priority,t.created_at))ifself.task_queue:taskself.task_queue.pop(0)task.statusTaskStatus.RUNNING self.running_tasks[task.task_id]task self._audit(task_scheduled,task)returntaskreturnNonedefcomplete_task(self,task_id:str,result:dict):任务完成记录结果、释放配额taskself.running_tasks.pop(task_id,None)iftask:task.statusTaskStatus.COMPLETED self.quota_manager.release_quota(task.tenant_id)self._audit(task_completed,task,resultresult)def_audit(self,event_type:str,task:AgentTask,**kwargs):不可变审计日志self.audit_log.append({event:event_type,task_id:task.task_id,tenant:task.tenant_id,timestamp:time.time(),**kwargs})控制平面的价值在于它不是告诉你“怎么做”而是确保“能做”和“做了之后可追溯”。3.3 用确定性工程约束概率性模型大模型的生成机制本质上是基于概率的序列预测。它倾向于给出“最可能”的下一个Token而非对事实或业务规则作形式化证明。概率性能力必须嵌入一个可控系统。具体落地可以采用“任务拆分模型分流”的策略classAdaptiveRouter:根据任务复杂度动态路由到不同处理路径defroute(self,task:dict)-str:complexity_scoreself._estimate_complexity(task)ifcomplexity_score0.3:# 简单任务轻量模型直接处理低延迟returnfast_pathelifcomplexity_score0.7:# 中等任务标准Agent流程returnstandard_pathelse:# 复杂任务多Agent协作 人工审核兜底returndeep_pathdef_estimate_complexity(self,task:dict)-float:# 基于Token数、工具依赖数、步骤预估等快速计算pass先以低成本、低延迟的路径满足多数“简单且明确”的请求仅当任务复杂度超过阈值时才升级到更强模型。在体验、成本与质量之间形成可管理的平衡点。3.4 把“Agent”从链路里拿出来多Agent系统的错误率是单Agent的指数级。一个务实的做法是把多Agent链路中每个“Agent”的调用都分类LLM必须的需要语义理解、生成或推理的步骤可以是普通函数的数据转换、格式化、条件判断可以是工具调用的API请求、数据库查询、文件操作把第二、三类从Agent链路里拿出来变成普通函数或工具——既降低错误率又节省大量Token成本。四、如何在第一曲线触顶前找到第二曲线4.1 警惕三个信号信号一你的工程投入超过了模型能力提升带来的收益。如果你花在调试框架、处理状态同步、解决并发问题上的时间已经超过了花在优化模型输出上的时间第一曲线正在放缓。信号二你的系统在“过度工程化”。Anthropic的工程团队有一句大实话“最成功的实现都没用复杂框架而是在用简单、可组合的模式。”如果你的系统越来越复杂、越来越难调试也许不是问题太复杂而是你的解决方案太复杂。信号三你还在为“下一个模型版本”做大量工程适配。模型每进一步你的工程价值就贬值一块。如果每次模型升级都意味着大量代码重写你的工程架构可能过度耦合了模型细节。4.2 三条行动建议第一从“堆Agent”转向“减Agent”。不是Agent越多越好——3-4个智能体是当前技术下的“黄金分割点”。把可以用确定性函数解决的问题从Agent链路里剥离出来。第二建立控制平面。即使你只有一个Agent在生产环境跑也要为“将来有一百个”做好准备。控制平面与执行平面分离——让调度、权限、审计、配额成为系统的一等公民而不是事后补丁。第三关注Harness Engineering而非Prompt Engineering。模型能力会继续提升但决定Agent能否真正进入生产环境的正在转向围绕模型建立的上下文、工具、权限、安全、反馈和治理体系。五、总结第二曲线不是放弃模型而是超越模型查尔斯·汉迪说第二曲线必须在第一曲线仍在上升时就开始。对于Agent系统开发者来说第一曲线是“模型能力”第二曲线是“工程体系”。模型能力仍在提升但其边际影响正在放缓。而Agent系统的工程复杂度——状态管理、并发控制、多租户隔离、故障恢复、成本治理——正在指数级增长。这两条曲线的交叉点就是Agent系统开发的“第二曲线拐点”。那些在这个拐点前完成转型的团队将从“追逐模型版本号”的被动跟随者变成“驾驭工程复杂度”的主动设计者。而那些继续在第一曲线上“堆Agent、堆Token、堆框架”的团队将在工程复杂度超过模型收益的那一刻发现自己已经掉进了“越努力、越亏损”的陷阱。模型会继续变强但决定胜负的从来不是谁用了最强的模型而是谁用最少的工程复杂度兑现了最多的模型价值。