摘要：2025 年，在 AI 业内，Agent 无疑是最热的。模型侧， 新一代 Agent Model 的能力大幅提升，支持更强大的长时规划和工具调用。同样，产品侧， Agent 也正在从简单的聊天助手进化为真实环境中持续交付的数字员工。

2025 年，在 AI 业内，Agent 无疑是最热的。模型侧， 新一代 Agent Model 的能力大幅提升，支持更强大的长时规划和工具调用。同样，产品侧， Agent 也正在从简单的聊天助手进化为真实环境中持续交付的数字员工。

但真正实际好用的 Agent 产品屈指可数，其实这也说明了 Agent 的 实际落地远远比我们预期中的更复杂 。

做 Agent 的真正卡点在哪？是技术还没到位吗？在 Agent 创业中，有哪些真实的教训和经验？现在做通用 Agent 产品，还有价值吗？......

Atom Capital 近期组织了一场闭门沙龙，邀请了硅谷和大陆专注 Agent 前沿的创业者和大厂技术专家，围绕 Agent 的这些难点进行了深入讨论，全是来自一线的实战心得、技术和业务洞察。

TLDR：

The Bitter lesson 依然生效，新一代Agent Model的"规划"和"工具调用"能力的提升，取代了过去大量基于规则的工作流编排等外围工程。

隐性知识的获取是一个Agent的核心挑战，尤其在2B领域。

Context，即隐性知识和业务逻辑的好坏决定了大模型如何能够在实际落地中完成任务，是否真正实现"可生产可交付"的价值。

Workflow跟自主编排Agent各有用武之地，会长期并行。但价值重心很明显正在逐步向后者迁移。

通用Agent的留存与付费转化偏弱，新客多、留存低成为常态，更务实的做法是从"通用"转向"垂直深耕"。即便在"通用"赛道，也先聚焦特定场景。

长期来看，真正的护城河在于几个核心能力：深度的环境理解与操作能力、持续的学习记忆闭环、针对特定场景的模型优化，以及多Agent间的协作标准。

今年Agent真正从"目标"变成了"手段"——过去大家谈论Agent更多是在描绘一个理想状态，现在则是在用它解决具体问题。随着底层模型能力加速进化，嘉宾们分享了痛苦的教训、面临的主要挑战以及相应的重心调整。

Bitter lesson：今年最大的Learning是什么？

之前做Agent的大量工程化工作都“交了学费”。 一位嘉宾分享，两年前他们开始做Agent的时候，模型能力还不够，GPT-4虽然智商ok，但也有各种问题，包括工具调用、准确性、上下文长度、速度等。他们因此做了很多外围的工程化，做了各种工具，去年他的产品在 SWE-Bench 测试中两次拿到榜首。可是这样的方案不具有通用性，也不稳定。今年Claude Code出来后，他发现，过去做的这些工作都没有意义，都被大模型吃掉了。模型本身就是Agent，开发者只需要给它环境，这对他的冲击非常大。

这个“交学费”的痛苦经历被多位嘉宾提及。教训的背后，是因为新一代Agent Model的"规划"和"工具调用"能力的提升，取代了过去大量基于规则的工作流编排等外围工程。

Agent目前最主要的挑战是什么？

隐性知识的获取是一个核心挑战，尤其在2B领域。 大模型能力不再是主要瓶颈，但是Agent如何能够给到大模型足够的context来实际落地，依然面临几个方面的挑战。

一是默会知识。 在真实世界真实场景中，有很多默会知识，而这些是没有被记录、AI不知道的。以广告行业为例，什么样的创意是好的创意，什么样的slogan是好的slogan，行业内人士可能需要梳理出一套规则给到AI。

二是协作需要的共识性知识。 在真实的组织中，人和人之间的协作是口耳相传的。一个大之下有小组织，每个小组也有自己的生态。以字节为例，大家都用Golang，但是每个小组用Go的方法都不一样。这些组织内部的共识性知识，目前是严重缺乏的。

三是企业内部在长期实践中形成的自定义规则。 一位嘉宾分享了一个真实案例，很具有代表性。他在帮助客户计算ACV（年度合同价值）指标时发现，虽然业界有标准算法，但企业实际操作时却面临着各种复杂情况：哪些合同应该计算在内，哪些不算？合同截止时间能否延期？出于某些实际考虑，不在结算周期内的合同需要如何特殊处理？每家企业的处理方式都不同。同样一个指标，不同公司的计算方法可能完全不同。即便是看似标准的 Salesforce，不同企业对同一字段的定义也不尽相同。这些源自业务实践的自定义规则与术语，都是外部难以直接感知的“隐性层”。

产生这些问题的本质，是AI完全改变了过去软件的工作方式。以前软件都是在做工具给人使用，因为工具直接解决问题的成本过高，问题由人来 解决 。在Agent时代，Agent需要直接解决问题，这就要求开发者把人脑如何解决问题的思路都做出来。这里包括默会知识、协作的共识性知识、各个企业内部自定义的规则等等。目前，Agent开发者花了大量时间和精力来构建这些context。

创业者应该在哪里发力？

聚焦上下文工程来构建环境。 因为大模型能力的迅速提升，Agent实施重点不再是模型与工具，而是如何构建环境让大模型更好地落地。这个转变很关键，因为"环境"很可能就是那层不会被大模型淹没的地基。

这里的“环境”包含三要素：

执行能力：让 Agent 在真实界面、终端与移动端进行 Computer Use。

业务连接：把企业系统、数据与权限工具化、可调度化。

上下文载体：承载领域术语、企业知识与使用习惯等关键信息。

其中最核心的是context，即隐性知识和业务逻辑。Context的好坏决定了大模型如何能够在实际落地中完成任务，是否真正实现"可生产可交付"的价值。

Agent创业过程中面临着很多选择，讨论下来，大家最关心的是其中两个：

技术路线：Workflow or Agentic？

现在落地较好的Agent，不少还是Rule-based（或者叫Workflow-base Agent）。到底是通过工作流让Agent按我们的预期完成任务，还是它能够自主编排完成？Workflow-based和Agent-based这两种技术路线的选择，是嘉宾们热烈讨论的一个议题。

一个实用的选择标准，是看客户的工作是否天然由工作流驱动。 对于企业里可以用非常强规则描述的工作，用Workflow去做，会更高效、准确，成本更低，合规性也更好。一位嘉宾分享了订单处理的案例，虽然订单格式千差万别（从微信、邮件、系统提交等），但订单收进来后，处理逻辑其实是一个固定的工作流。用Workflow做这种订单处理效果非常好。有家制造业企业在部署订单处理Agent后，一下子节省了十多个人的工作。

这一类工作，也可以让自主编排的Agent去做，因为模型能力越来越强了。但是这样每次都要做Planning，消耗很多Token，而且每次过程都不是事先规划好的，对企业来讲，它不一定合规。在真实的企业场景中，嘉宾们看到多数能落地的Agent还是Workflow-based。

需要多步骤、灵活操作的任务，则更适合交给自主编排Agent。 比如数据分析，这种工作无法用Workflow描述，或通过一个简单的功能解决。它要读取数据，读完数据之后做分析，分析完之后可能还要做报告。在整个过程中，它还要反复地查询数据。这是很典型的一种用Agentic loop来实现的场景。

很多2B领域的Agent公司过去两年犯的一个错误，是在模型还没有那么强、整个Agent的工具生态还没有那么丰富的时候，把本来应该用Agentic解决的问题，简单化地去用Workflow解决了。这就导致一个问题：用很局限的方式完成一个更复杂的任务，结果方案的灵活性、泛化性都不好。而当模型能力真正提升时，就有新的创业者利用大模型的能力、真正用Agentic方式来实现需求，相当于降维打击了。

需要强调的是，两条技术路线之间的转换并不意味着完全推倒重来。企业过往积累的流程机器人、系统适配与集成连接，正好可以被"工具化"，为Agent所用。比如，RPA公司沉淀的RPA资产可以转化为MCP Server中的工具，企业原先接入的系统可以直接转化为Agent落地的基础设施优势。

Workflow跟自主编排Agent各有用武之地，会长期并行。但价值重心 很明显 正在逐步向后者迁移。

商业化路线：KA or SMB？

对2B领域的Agent创业者而言，另一个重要决策是在客户选择上：先攻KA（大客户）还是SMB（中小客户）？

从营收看，大客户确实更有吸引力——预算充足、付费意愿强、单个项目价值高。但KA市场有几个不可忽视的挑战：实施成本高昂、决策链条冗长、各部门利益协调复杂。很多项目最终卡在"试点成功但无法推广"的尴尬境地。

SMB市场则呈现出截然不同的机会。一位嘉宾分享了一个有趣的案例：许多中小企业CEO在看到他的Agent处理后的数据报告时，惊讶地感叹："这些数据我从来没见过。" 原因很简单：以前中小公司不可能雇佣专门的运营分析人员，成本太高。许多决策都是靠CEO的经验和直觉判断。而现在，AI正在将过去只有大组织才配备的专业运营能力"民主化"，让标准化流程管理变得"即插即用"——这是企业级服务市场迎来的历史性机遇。

理解了这两个市场的不同特征后，更务实的做法是分层并进：用中小企业市场快速验证产品价值和商业模式，积累标准化场景，打磨"低实施成本加标准SOP加轻量集成"的产品形态；同时选择性地用能量化价值的案例敲开关键大客户的大门，建立标杆项目。

另外，现阶段巨头内部对推进AI也有不同的担心。比如，公司无法量化使用产品后生产力究竟提升了多少。现在主要是自下而上的员工有热情，但决策层很难决定是否投入，因为无法证明生产力提升。另外，一些巨头更关注实际的收入，对创新不是很感兴趣，认为追赶是最有效的策略。

"万能工具"的困境

作为头部通用Agent，Manus做得很出色。它是第一个出圈的通用Agent，营销做得非常好。它的产品Demo很炫酷，特别是AI操作电脑和浏览器过程的可视化，以强烈的科幻感激发了用户对AI的无限想象，从而吸引了大量用户并显著提升了品牌效应。

这类通 用Agent的一个问题，是大家使用久了以后 发现，实际体验往往难以达到预期。最大卡点在于"面面俱到，却难以做到最好"，在具体场景的深度与质量上普遍"只到60分"。用户在实际使用中，往往会转向更专业的工具——做网站用专门生成器，写代码用编程助手，做调研用研究助手……导致通用Agent的留存与付费转化偏弱，新客多、留存低成为常态。

聚焦垂直的价值——以 PPT Agent 为例

对资源有限的创业公司而言，更务实的做法是从"通用"转向"垂直深耕"。即便在"通用"赛道，也先聚焦特定场景，在规划自动化的基础上引入专用模型与专业工具链，围绕具体任务做深做透。

这里以一位头部PPT Agent负责人所分享的经验为例：

如果用一个粗略的评分标准做参照：普通人做的PPT大概60分（刚及格），专业高手能到80分，乔布斯苹果发布会那样的顶级路演是100分；而目前通用大模型PPT 能力多在四五十分，只能“搭个架子”。

如何提升Agent的PPT 能力，让大模型跨过这几十分的差距？

拆解下来，PPT制作主要有三个环节：

内容生成： 这是第一步，也是基础。用户通常会给出指令，要求Agent收集相关信息。内容的质量、丰富度和准确性至关重要。如果内容本身就不好，后面的环节都会受影响。这部分核心考验的是Agent的强检索与综述能力，决定了PPT上限。

排版与视觉设计： 收集到内容后，如何将其合理排版并呈现出良好的视觉效果，这是PPT区别于普通文档的关键。

数据图表可视化： PPT中经常需要展示数据。原始数据多是文字或数字，需要将其恰当地转化为曲线图、柱状图、流程图等可视化形式。

现阶段，AI生成PPT的普遍做法是“模板 + 大模型适配”，并用代码生成完成排版和视觉设计。但这种方法容易出现一些 系统性瑕疵（ 宽高比不对、元素重叠、比例失调等），因为代码生成的视觉和排版设计沿用了网页生成的逻辑，缺乏针对PPT场景的优化。

这位嘉宾所在团队围绕PPT场景做了深入优化：在内容检索与排版视觉这两个环节分别训练了专用模型，通过纠错与蒸馏提升模型在 PPT 领域的表现；同时补齐多样工作流（从“只美化现有 PPT”到“按既定大纲排版与制图”）、对接个人历史素材与企业知识库、遵循组织模板与品牌规范等等。

结果也验证了这条路径的有效性：其产品生成PPT的质量显著优于通用Agent。通用 Agent 的用户留存率普遍只有约10%，而该PPT Agent可达到20%以上，在竞争中形成了清晰差异化。

未来，Agent 是否像人一样操作电脑、还是 API 就行？

Agent通过GUI操作电脑的能力正在快速成熟。嘉宾们分享了很多令人印象深刻的实践案例：QA测试Agent能够像人一样打开浏览器测试网站，小红书发帖Agent可以批量操作图片选择、打标签并发布内容。o3模型几乎不需要特殊定制就能直接使用，对常见UI界面的识别和操作能力已相当成熟……

但GUI操作的长期价值仍存在很大争议：GUI本质上是为人类认知优化的界面，对Agent来说并非最优路径。当Agent能直接调用API、操作服务器甚至编写代码时，绕开GUI似乎是更优解。在这种情况下，还有什么必要坚持GUI操作吗？

我们有两点考虑：一是现实世界过去几十年积累了大量基于GUI的应用，短期内完全绕过并不现实。而更深层的原因，在于GUI承载的不仅仅是操作功能，还有丰富的上下文信息。人类选择GUI而非纯语言操作，很大程度上是因为视觉能够提供丰富的场景信息和认知优势。如果未来Agent在视觉理解上的能力获得提升，甚至超越人类，GUI操作的价值可能会重新凸显。

如何设计人与Agent交互的颗粒度？

Agent产品设计中最困难的问题之一是确定交互颗粒度：什么时候需要用户确认？什么时候应该主动询问更多信息？

以旅行规划为例，这个看似简单的场景实际上包含大量个人偏好。如果用户要求Agent制作东京七天的旅行计划，Agent直接去执行可能无法满足需求。实际上，Agent需要了解很多信息：用户是否去过东京？喜欢什么风格的旅行？预算范围如何？之前去过哪些地方，有什么特别喜欢的体验可以作为参考？但如果过度询问用户偏好，又可能让用户感到繁琐。

要解决好这个问题，关键在于Agent要具备判断能力：什么情况下需要更多信息，什么情况下可以基于常识推进。最有潜力的方案是让Agent在交互过程中逐步学习用户偏好，记住修正和反馈，在后续交互中主动应用这些知识。 比如，LemonAI最近演示的产品，正在尝试通过学习用户的偏好来制定旅游计划。

未来人与Agent将如何协作？——来自管理学的启发

传统管理学中的情境领导理论将管理模式分为四种：指导（Directing，明确告诉下属每一步怎么做），教练（Coaching，与下属充分讨论，然后以管理者为主导来做决定），支持（Supporting，管理者提供建议但由下属主导决策），授权（Delegate，完全放手让下属去做）。情境领导的核心，是管理者必须了解下属的能力范围，采取相应的管理模式。

利用这套框架来思考人与Agent的协作，会发现Agent与人的协作关系要复杂得多。Agent在不同维度的能力差异巨大：它可能在某些方面表现卓越，在另一些被认为是常识的领域却会判断错误。更具挑战性的是，Agent可能会自主做出超出权限的决策，比如调用昂贵的API却不考虑成本，或在需要人工审批的环节直接推进。这种能力分布的不均，要求对Agent采用更加精细化的管理策略。

实践中最有效的方法是建立共享上下文机制。这不是简单的信息同步，而是让Agent理解它所处的工作环境、可用的工具和权限边界、协作的规则以及核心目标，以及什么时候需要请求人工确认。

一个有趣的趋势是，最先进的AI产品正在尝试让AI更主动地参与协作。Agent不再是被动的执行工具，而是会主动提出建议，并在遇到困难时主动请求人工协助。

多Agent架构为何难以落地？

在多Agent协作的探索上，许多嘉宾也分享了在落地中遇到的挑战。最核心的矛盾是：如果所有Agent共享全部上下文，并不是真正的 “多Agent协作”；但要从庞杂上下文里精准抽取每个Agent所需的部分，又是个极大的挑战。抽取不准，交接就会立刻失败；共享过头，又会退化成一个超长System Prompt的“单体Agent”。如何抽象出各个agent和所属的context，还需要更多的实践。

许多开发者尝试多Agent协作的动机很朴素：上下文越长，大模型越“笨”。当问题变成几十步、上百步，单体Agent容易在中途“绕回去”——前几步还能跟上，越到后面就越容易进入自我循环。理论上，把超长的推理链路拆分成可管理的子问题，由多Agent来分别解决，可以缓解Context过长导致的模型变笨问题。但在真实业务中，何时切分子任务、如何调度合适的Agent，成为了最大卡点。

有效的路径可能是采用任务分解加专家模型的组合：把复杂问题拆解成相对独立的子任务，每个子任务由擅长该领域的Agent处理。整个流程类似MapReduce模式——调度分发、并行处理、结果归并，关键是要做到可观测和可回溯。

更进一步的思路是引入Agent-to-Agent的异步协作机制，把一致性、延迟和成本等工程约束纳入系统设计。比如，某些子任务可以容忍一定的信息延迟，某些关键决策则需要实时同步。这样既能保证协作效果，又能控制系统复杂度。

随着大模型公司纷纷推出Agent产品，"Agent是否会被大模型淹没"再次成为萦绕在创业者心头最大的疑问。一个具有代表性的对照案例，便是 Coding Agent 赛道中的 Cursor 与 Claude Code。

Claude Code代表了“大模型上探”的产品路径：把“规划—执行—复盘”内生到模型，强化长程规划与连续Tool Use的能力，尽可能以一次对话承载更多自治工作。依托模型厂商的数据闭环与算力优势，强调“模型即Agent”的一体化体验。

Cursor代表了“Agent下沉到环境”的路径：通过IDE这一真实执行环境，提供高质量的上下文供给、工具与权限治理、成本与合规控制，强调把智能稳定落在生产一线。

短期内，两种路线会并行发展，但长期来看，真正的护城河在于几个核心能力：深度的环境理解与操作能力、持续的学习记忆闭环、针对特定场景的模型优化，以及多Agent间的协作标准。

创业者要提前关注模型 哪些 能力的提升？

面对大模型公司可能的降维打击，Agent创业者需要提前布局/关注那些可能改变游戏规则的技术拐点。我们认为，大模型在如下四个领域的能力进展尤其值得创业者关注：

长期规划与连续行动能力提升： 以Claude Code为代表的一方Agent产品（大模型公司推出的Agent产品），能够积累许多真实场景下的高质量人机协作数据，而一旦下一代的大模型训练从这些数据中学会长任务策略，可能就意味着“模型即Agent”时代的到来，也意味着那些以复杂工作流编排为核心竞争力的Agent产品可能会遭遇降维打击。

多模态深度融合： 如果图像、语音、自然语言深度整合到同一个模型中，AI能真正像人一样同时"看、听、说"时，交互方式将发生根本性变化。特别是在老人、儿童和跨语言场景中，这种突破意味着技术普惠的真正实现，创造出巨大机会。谁能率先在这些细分场景做出差异化产品，就能建立先发优势。

界面自动生成： 随着模型意图理解和视觉生成能力的提升，未来可能不再有标准化的界面设计。甚至可以想象，AI可以根据用户当下的任务、心情甚至时间，实时生成最适合的界面布局。这将彻底改变人们对软件产品的认知，也是重新定义软件产品的机会。创业者可以围绕动态界面的设计理念和实现方案建立新的产品品类。

更成熟的Context Engineering与记忆机制： 围绕企业知识、规则与偏好，构建可持续沉淀与演进的上下文体系。企业级的上下文管理将成为新的竞争高地，这是大模型公司难以直接切入的专业化领域。

未来会是一个还是多个模型？

在实践中，创业者们越来越清晰地感受到：不同模型在能力侧重、风格取向与行为倾向上存在系统性差异，且这些差异并非简单的“强弱”维度，而是“偏好-能力”的多轴分布。

嘉宾们分享的经验：

不同大模型的能力侧重不同。ChatGPT 在战略思考与架构抽象上，更凝练、结构清晰、思考更深；Gemini覆盖面广但偏铺陈、信息密度一般，更适合承接架构做详细设计；Claude规划能力最强，通用Agent的自主规划基本都用它做，它的代码能力也最强。

做成Agent后，各模型的“行动冲动”也有所不同：有的模型遇到模糊意图时会立刻尝试执行，容易越权或忽视成本约束；有的则倾向先追问、再确认。

基于此，比起追求一个“无所不包、可瞬时切换人格”的超级模型，现阶段更务实的做法是多模型分工与编排。利用这些大模型间的差异，把它们纳入产品的不同流程，让Agent在真实场景中更高效、可控且成本更低。

学习能力是关键

从人与Agent的交互到多Agent协作，核心挑战都指向了同一个方向：AI的学习能力。Agent需要在与用户的交互过程中不断学习用户的偏好、工作习惯、决策模式，更要掌握业务流程中那些没有明文规定的隐性规则。

这种学习远不是简单的参数微调，而是对特定场景下上下文的深度理解和长期记忆。就好像一个优秀秘书的价值在于比老板更懂老板的需求——知道什么时候该打断会议，什么邮件需要优先处理，哪些"紧急"任务其实可以缓一缓。Agent要达到这个水平，必须建立起基于场景的记忆和学习机制。

然而，当我们深入探讨这种学习机制的具体实现时，会发现Agent的学习困难不仅仅是技术实现问题，要真正解决Agent的学习能力问题，我们需要回到最基础的认知科学层面，重新审视记忆的本质结构。

记忆的底层瓶颈

从认知科学角度看，人脑的记忆分为三种类型：Semantic Memory（概念记忆，存放“是什么”的知识与概念关系）、Episodic Memory（情景/场景记忆，按时间线记录“在什么情境下、经历了哪些步骤、做过哪些尝试、得到了什么反馈”的具体经历），以及 Procedural Memory（程序记忆，类似“肌肉记忆”，用于稳定复现已掌握的技能动作，需要从情景记忆中反复提炼才能形成）。

当前AI系统在Semantic Memory方面已经做得不错，但在Episodic Memory方面几乎是空白。这也解释了为什么AI在编程领域表现突出、但在多数行业落地困难：代码本身记录了完整的"如何做"的过程，包括版本控制、失败案例、调试过程等，为AI提供了丰富的Episodic Memory。而在其他领域，这种过程性数据极度稀缺， web语料说的是"什么“，是结果 。企业很少公开分享失败经验，即便分享也往往经过美化。销售如何失败？项目为何延期？决策如何出错？这些宝贵的学习素材很难在公开语料中找到。没有持续学习与情景记忆，Agent很难快速适应复杂上下文，仅靠抽象规则难以维持稳定表现。

Procedural Memory类似人的肌肉记忆。 一个网球运动员在球打过来的时候，他的动作不是经过思考的，是他在长期训练过程中提炼的。所以他 能够重复低成本、可靠地复制。 AI 如何将知识沉淀下来、如何把经验真正变成程序记忆，目前还很遥远。

情景记忆的探索方向

很遗憾，大模型在记忆和学习方面一直进展缓慢。情景记忆是提升学习能力很好的切入点，可能需要几个方向的探索。

首先是过程数据的主动收集。 传统AI系统往往只关注最终结果，但情景记忆的核心在于记录完整的决策链条。这意味着Agent在执行任务时，需要详细记录每一步的决策逻辑、遇到的障碍、尝试的解决方案，以及用户的实时反馈。比如Cursor记录的用户行为（对Agent的建议是接受、修改还是拒绝等具体场景）对它的产品持续优化就很有价值。

其次是人机协作轨迹的深度学习。 最有价值的学习往往来自高质量的人机协作案例。当用户纠正Agent的错误、调整执行策略或提供关键补充信息时，这些互动轨迹蕴含着丰富的隐性知识。Agent需要从这些协作模式中提取可复用的决策框架，而不是简单地记住表面的操作步骤。

第三个方向是场景化学习机制的建立。 不同情境下的最优策略往往截然不同，Agent需要具备根据当前场景快速调用相关经验的能力。这要求系统能够识别场景的关键特征，并建立场景与策略之间的动态映射关系。

最后是可持续的上下文演进能力。 记忆不应该是静态的存储，而应该是一个随着使用而不断优化的动态系统。Agent需要能够识别哪些经验在新情境下仍然适用，哪些需要调整，哪些已经过时需要淘汰。

一些前沿公司已经开始在这个方向上探索。比如LemonAI在旅行规划领域的尝试，通过记录用户对初始计划的修改和反馈，持续改进推荐算法的准确性。虽然这种方法还处在早期阶段，但它代表了从结果导向转向过程导向的重要思路转变，为未来Agent的发展指明了方向。

来源：晚晚的星河日记一点号