借助 Coding Agent 等工具，如今构建一个 AI 产品的技术门槛和启动成本已急剧降低。一夜之间，将想法变为可交互的原型变得前所未有的容易。但一个刺眼的矛盾也随之浮现：大多数 AI 产品仍在走向失败。如果技术实现不再是瓶颈，那么问题究竟出在哪里？
Aishwarya Naresh Reganti 和 Kiriti Badam 曾在 OpenAI、Google、Amazon、Databricks 等公司参与构建并成功推出了 50 多个企业级 AI 产品。最近，他们在播客节目中，与主持人 Lenny 细致分享了当前 AI 产品开发中的常见陷阱与成功路径。基于该播客视频，InfoQ 进行了部分删改。
核心观点如下：
今天构建的成本已经非常低了，真正昂贵的是设计，是你是否真正想清楚了产品要解决什么痛点。对问题本身和产品设计的执着，是被低估的，而单纯追求“快点做出来”，是被高估的。
AI 不是答案，而是解决问题的工具。
领导者需要重新回到“亲自上手”的状态，并不是要他们亲自实现系统，而是为了重建判断力，接受“我的直觉可能不再完全正确”这一事实。
“忙碌但无效”的工作时代正在结束，你不可能再躲在角落里做对公司没有实质影响的事，而必须思考端到端的流程，以及如何创造更大的影响。
在这个数据随时告诉你“你大概率会失败”的时代，保留一点愚蠢的勇气很重要。
AI 产品构建中的挑战
Lenny：目前 AI 产品构建的情况是怎样的？哪些进展顺利，哪些地方问题依旧明显？
Aishwarya：首先，怀疑态度明显减少。2024 年还有很多领导者认为 AI 可能只是又一波“加密货币式”的泡沫，因此迟迟不愿真正投入。当时我看到的很多所谓“AI 用例”，更像仅仅是“在你自己的数据上套一层 Snapchat 滤镜”。
而 2025 年，很多公司开始真正反思用户体验和业务流程，逐渐意识到：如果想构建成功的 AI 产品，必须先拆解现有流程，再重新构建。而消极的一面在于，执行依然非常混乱。这个领域只有三年左右的历史，没有成熟的方法论，也没有教材，大家基本都是边走边学。
同时，AI 产品的生命周期与传统软件截然不同。这导致了以往在 PM、工程师、数据团队之间形成的分工被打破。过去，PM、工程师各自优化各自的指标；现在，大家可能需要坐在同一间会议室里，一起看 agent 的执行轨迹，共同决定产品应该如何表现。这种协作更紧密，也更复杂。
Lenny：你之前说构建 AI 产品与构建非 AI 产品本质上非常不同，能具体谈谈吗？
Aishwarya：构建 AI 系统和传统软件系统之间确实存在大量相似之处，但也有一些根本性的差异，足以改变你构建产品的方式。其中一个经常被忽视的核心差异，是“非确定性”。
与传统软件相比，你几乎是在与一个非确定性的 API 打交道。在传统软件中，决策引擎和流程往往是清晰、可预测的。以 Booking.com 为例：你有一个明确意图，比如在旧金山订两晚酒店，系统通过一系列按钮、选项和表单，把你的意图转化为具体操作，最终完成目标。
但在 AI 产品中，这一层被一种高度流动的、以自然语言为主的界面所取代。用户可以用无数种方式表达同一个意图，这意味着你无法预判用户的输入行为。而在输出端，你面对的是一个概率性的、非确定性的 LLM，它对提示词极其敏感，本质上还是一个黑箱。你既无法完全预测用户会如何使用产品，也无法确定模型会给出怎样的回应。
因此，你同时面对输入、输出和中间过程三方面的不确定性，只能在有限理解的基础上去预判行为并进行设计。到了 Agent 系统，这种复杂性会进一步放大。
这也引出了第二个关键差异：代理性与控制权之间的权衡。很多人执着于构建高度自治的系统，希望 Agent 能替人完成所有工作。但每当你把决策权交给 AI，你就必然放弃一部分控制权。因此，只有当系统足够可靠、足以赢得信任时，才值得赋予它更高的自治能力。这正是“代理性—控制权权衡”的核心：自治越高，控制越少，而信任必须通过时间和表现来积累。
Kiriti：类比登山：如果你的目标是攀登一座高峰，你不会第一天就直接冲顶，而是先进行基础训练，逐步提升能力，最终才接近目标。
构建 AI 产品也是如此。你不应该在第一天就打造一个拥有公司全部工具和上下文的全能 Agent，并期待它能正常工作。正确的做法，是刻意从影响范围小、人工控制强的场景开始，逐步理解当前能力边界，再慢慢增加自治性、减少人工干预。
这样做的好处在于，你会逐渐建立信心，清楚 AI 能解决问题的哪一部分，以及接下来需要引入哪些上下文和工具来改进体验。好的一面是，你不必一开始就面对复杂而炫目的 Agent 体系；挑战在于，你必须接受“循序渐进”的现实。但几乎所有成功的案例，都是从极简结构起步，再不断演化而来的。
Lenny：你们一直强调“从低自治、高控制开始”，再逐步升级。能否用一个具体例子说明这种路径？
Kiriti：客户支持是一个非常典型的场景。我们在发布产品时也经历过类似情况，随着新功能上线，支持请求会突然激增，而且问题类型非常多样。
一开始，并不是把所有支持中心文章一股脑塞进 Agent 就完事了。更合理的第一步，是让 AI 为人工客服提供建议，由人类判断哪些建议是有用的、哪些是无效的。通过这个反馈回路，你可以识别系统的盲点并进行修正。
当你建立起足够信心后，才可以让 AI 直接向用户展示答案。接着，再逐步增加复杂能力，例如自动退款、创建功能请求等。如果在第一天就把这些能力全部交给 Agent，系统复杂度会迅速失控。因此，我们始终建议按阶段构建，逐步提升自治水平。
Lenny：一开始是高控制、低自治，AI 只给建议，最终决策仍由人来做；当系统被验证可靠后，逐渐赋予更多自治权，同时减少人工干预。只要这一阶段进展顺利，就可以继续向前推进。
Aishwarya：从更宏观的角度看，AI 系统的核心在于“行为校准”。你几乎不可能在一开始就准确预测系统行为，因此关键在于避免破坏用户体验和信任。做法是，在不影响体验的前提下，逐步减少人工控制，并以不同方式约束自治边界。
以医疗保险预授权为例，某些低风险项目，比如血液检测或 MRI，只要患者信息齐全，就可以由 AI 自动审批；而高风险项目，如侵入性手术，则必须保留人工审核。在这个过程中，你还需要持续记录人类的决策行为，构建反馈飞轮，用于不断优化系统。这样既不会损害用户体验，也不会削弱信任，同时还能让系统持续进化。
Lenny：你还给出过一些很好的分阶段示例，比如 Coding Agent：第一阶段只做行内补全和样板代码建议；第二阶段生成测试或重构代码供人审查；第三阶段则可以自动提交 PR。营销助手也是类似路径：从文案草稿，到完整活动执行，再到自动 A/B 测试和跨渠道优化。
Aishwarya：换个角度看，这种非确定性其实也是 AI 最迷人的地方。相比点击复杂的按钮，人类更习惯用语言交流，这大大降低了使用门槛。但问题在于，人类表达意图的方式极其多样，而你往往需要在非确定性的技术之上，达成确定性的业务结果，这正是复杂性的来源。
Lenny：所以，当人们一上来就想直接跳到第三阶段，往往会陷入困境：系统既难以构建，也不可靠，最终只能被判定为失败。
Kiriti：在达到高度自治之前，你需要对系统能力建立足够信心。如果一开始就从错误的切入点出发，你会面对成百上千种错误，却根本无从修复。
从小规模、低自治开始，不仅降低风险，也会迫使你认真思考“我要解决的到底是什么问题”。在 AI 快速发展的环境下，人们很容易沉迷于复杂解法，而忽视真正的问题本身。通过逐步提高自治层级，你可以清晰地拆解问题，并为未来扩展做好准备。
Aishwarya：我最近读到一篇研究指出，约 75% 的企业认为“可靠性”是他们在 AI 项目中面临的最大问题，这也是他们迟迟不敢将 AI 产品直接面向用户的重要原因。正因如此，目前很多 AI 产品更多集中在提升生产力，而不是彻底替代端到端流程。
Lenny：在这期节目之前，我们还录了一期，专门深入讨论了提示注入（prompt injection）和越狱（jailbreaking）。在那期讨论里，我们意识到这对 AI 产品来说几乎是一个“生存级风险”：它可能既没有成熟解法，甚至在理论上也很难被彻底解决。
Aishwarya：一旦 AI 系统真正进入主流应用，这会成为一个非常严重的问题。现在大家还忙着把 AI 产品做出来，很少有人认真对待安全性，但这迟早会爆发。尤其是在面对非确定性 API 的情况下，你几乎无法完全防范。
Lenny：我们当时聊到的一个核心问题是：要诱导 AI 去做“不该做的事”，其实并不难。虽然大家都在构建各种护栏系统，但事实证明，这些护栏并不牢靠，总能被绕过。而正如你所说，当 Agent 越来越自治、甚至进入机器人系统时，这种风险会被成倍放大，确实让人感到不安。
Kiriti：我同意这是一个真实存在的问题。不过从当前 AI 在企业中的采用阶段来看，大多数公司甚至还没真正走到能充分获益的程度。2025 年确实是 AI Agent 和企业尝试落地 AI 的一个高峰期，但整体渗透率依然不高，很多流程还远未被真正改造。
在这种情况下，只要在关键节点引入“人在回路”（human-in-the-loop），其实可以规避相当一部分风险。我个人更偏向乐观的一侧：与其一开始就被潜在的负面场景吓退，不如先尝试去落地、去使用。我们在 OpenAI 接触过的企业中，几乎没有人会说“AI 在这里完全帮不上忙”，更多是发现它能在某些具体环节上带来优化，然后再思考如何逐步采用。
Lenny：有哪些成功构建 AI 产品的模式和工作方式？
Aishwarya：我们合作过的成功公司，通常都具备三个维度：优秀的领导者、健康的文化，以及持续推进的技术能力。
首先是领导者。我们参与过不少企业的 AI 转型、培训和战略制定。很多领导者过去十到十五年积累的直觉，正是他们成功的基础，但在 AI 出现之后，这些直觉往往需要被重新学习。领导者必须愿意承认这一点，甚至需要一定程度的“脆弱感”。我曾和 Rackspace 现任 CEO Gajen 共事。他每天清晨都会预留一个固定时段，专门用来“补课 AI”——听播客、看最新资料，甚至在周末做白板推演。领导者需要重新回到“亲自上手”的状态，并不是要他们亲自实现系统，而是为了重建判断力，接受“我的直觉可能不再完全正确”这一事实。很多真正成功的团队，正是从这种自上而下的转变开始的。AI 几乎不可能靠纯粹的自下而上推动，如果领导层对技术缺乏信任，或者对能力边界有误判，整个组织都会受限。
第二个维度是文化。在传统企业中，AI 往往不是核心业务，但因为竞争对手在用、因为确实存在可行用例，企业不得不引入 AI。在这个过程中，恐慌文化非常常见，比如“FOMO”“你会被 AI 取代”等说法。问题在于，真正做出好 AI 产品，极度依赖领域专家；但很多专家却拒绝参与，因为他们担心自己的岗位被替代。这时，领导者需要建立一种“赋能型文化”，强调 AI 是用来增强个人能力、放大产出的工具，而不是威胁。只有这样，组织才会形成合力，而不是人人自危。事实上，AI 往往会创造更多机会，让员工做更多、更高价值的事情。
第三个维度才是技术本身。成功的团队通常对自身工作流有近乎执念般的理解，清楚哪些环节适合 AI，哪些地方必须有人参与。几乎不存在“一个 AI Agent 解决一切”的情况。通常是机器学习模型负责一部分，确定性代码负责另一部分。因此，关键不在于迷信技术，而在于为每个问题选择合适的工具。
此外，这些团队也非常清楚自己在和一个非确定性的 API 打交道，因此会以完全不同的节奏推进开发。他们迭代得非常快，但前提是不破坏用户体验，同时快速建立反馈飞轮。如今的竞争焦点，并不是谁最早上线 Agent，而是谁最早构建起持续改进的机制。凡是有人告诉我，“一个 Agent，两三天就能在你系统里跑出显著收益”，我都会非常怀疑。这不是模型能力的问题，而是企业数据和基础设施本身就极其混乱。大量技术债、混乱的接口和命名方式，都需要时间去消化。真正能产生显著 ROI，通常至少需要四到六个月，即便你拥有最好的数据和基础设施。
Lenny：有些人认为评测（eval）是解决 AI 问题的关键，有些人则觉得它被严重高估，只要“感觉对了”就行。你们怎么看 eval？它在多大程度上真的能解决你们提到的那些问题？
Kiriti：我觉得大家陷入了一种错误的二元对立：要么 eval 能解决一切，要么线上监控能解决一切。eval 本质上，是把你对产品的理解、你的价值判断，编码进一组数据集：什么是重要的，什么是绝对不能发生的。而生产环境监控，则是在产品上线后，通过关键指标和用户行为，反馈真实使用情况。
这种监控并不新鲜，但在 AI Agent 场景下，颗粒度变得更细了。除了显式反馈，比如点赞、点踩，还有大量隐式信号。例如用户不点踩，但反复要求重新生成回答，这本身就是强烈的负面反馈。
真正的问题不在于“选哪个”，而在于你想解决什么。如果你的目标是构建一个可靠系统，那么上线前必须有底线测试，这可以是一小组关键问题，确保无论如何都不能出错。上线之后，你不可能人工检查所有交互轨迹，这时就需要监控来提示你哪里出了问题。当你发现新的失败模式，再反过来构建新的 eval 集。这个循环缺一不可。认为“只靠其中一种就够了”，在我看来是站不住脚的。
Aishwarya：我想稍微退一步，谈谈为什么“eval”这个词在 2025 年下半年被赋予了如此沉重的含义。你去找数据标注公司，他们说专家在写 eval；有人说 PM 应该写 eval，它们就是新的 PRD；还有人说 eval 本身就是产品改进所需的完整反馈回路。对初学者来说，这非常混乱。
事实上，大家说的都不完全错，但指向的是不同层面的事情。律师和医生写的“评估”，并不等于他们在构建 LLM judge；PM 写 eval，也不意味着要写一个可直接上线的评判模型。很多时候，你事前根本无法判断是否需要 LLM judge，还是只依赖生产环境的用户信号。
Martin Fowler 曾提出过“语义扩散”这个概念：一个词被发明出来，随后被不断滥用，最终失去精确定义。我认为 eval 正处在这个阶段。不同人看到的是它的不同侧面。但如果你让一群实践者坐在一起问：“AI 产品是否需要一个可执行的反馈回路？”他们一定都会点头。至于怎么做，完全取决于具体场景。复杂用例下，盲目构建评判模型往往得不偿失，这时回到用户信号、快速修复、确认是否回退，反而更有效。最终，所有资深从业者都会告诉你一句话：一切取决于上下文，不要迷信固定方法论。
Lenny：现在“eval”已经变成一个可以指代无数不同东西的词，既包括标注、基准测试，也包括反馈机制，讨论起来反而更混乱了。
Aishwarya：我最近就遇到一个客户，说他们“在做 eval”。我问能不能看看数据集，他们说只是看了 LLM Arena 和一些第三方榜单，就选了模型。我只能说，那不是 eval，那只是模型对比。
Lenny：Claude Code 的负责人 Boris 曾公开表示：“我们在 Claude Code 里不做 eval，一切靠感觉（vibes）。”能不能请你分享一下，Codex 以及 Codex 团队在 eval 这件事上的具体做法？
Kiriti：在 Codex，我们采取的是一种相对平衡的方式：eval 是必要的，但同时必须高度重视用户反馈。我们在产品上极度强调“把正确的产品做出来”，而其中非常重要的一部分，就是认真倾听用户的声音。
Coding Agent 和其他领域的 Agent 有一个本质差异：它们是为“可定制性”和“工程师”而生的。Coding Agent 并不是只解决五六个固定工作流的产品，而是需要以多种方式被定制和扩展。这意味着，产品会被嵌入到各种不同的集成环境、工具链和使用场景中。在这种前提下，几乎不可能为用户的所有交互方式提前构建一个完备的 eval 数据集。
但与此同时，你仍然需要确保，每一次改动至少不会破坏产品中那些最核心的能力。因此，我们确实会用 eval 来守住这些“底线”。同时，我们也投入大量精力去理解用户真实的使用方式。举个例子，我们最近推出了一个代码审查产品，增长非常快，既帮 OpenAI 内部发现了大量问题，也被外部客户广泛使用。如果我对代码审查相关的模型、或训练时采用的强化学习机制做了调整，在上线之前，我一定会通过 A/B 测试来验证：它是否还能准确找出关键问题，用户对结果的反应如何。
有时，用户一旦被错误的代码提示反复打扰，甚至会直接关闭这个功能。你需要确保，新版本确实在“做对的事情”。但老实说，很多这类场景在事前是很难预判的，也很难提前为它们构建对应的 eval 数据集。因此，这里面既有一定的“vibes 判断”，也有大量来自真实用户的反馈。我们会非常主动地关注社交媒体，看看是否有人遇到特定问题，并尽快修复。
我并不认为有一套万无一失的 eval 指标，可以完全依赖它，其他什么都不用管。每当我们要发布一个新模型，团队都会聚在一起做集中测试，每个人关注不同的重点。我们手里有一份“高难度问题清单”，会把这些问题交给新模型，观察它的表现。这更像是每位工程师都有一套针对自身关注点的定制 eval，用来帮助大家理解：在这个新模型下，产品到底发生了什么变化。
CC/CD 框架
Aishwarya：我们接触过大量公司，它们都承受着来自竞争对手的压力，因为“所有人都在做 Agent”，于是觉得自己也必须构建一个完全自治的 Agent。但很快发现一个问题：在一开始，你根本无法预知用户会如何与系统交互，也无法预判 AI 会给出哪些响应或采取哪些行动。当你的工作流包含四五个步骤、需要连续做出大量决策时，问题一旦出现，就会变得极其难以修复，结果往往是无休止的调试和热修复。
我们曾为一个客服场景构建系统，后来，因为热修复多到失控，新的问题层出不穷，这个产品不得不被下线。与此同时，行业里也发生了不少令人警惕的事件，比如前段时间 Air Canada 的一个 Agent“臆造”了一条并不存在的退款政策，而公司因为法律原因不得不接受这个结果。这类案例让人意识到：如果设计不当，AI 系统可能会对企业本身造成非常严重的风险。
正是在这样的背景下，我们开始思考：如何在不失去用户信任的前提下构建系统，同时又能形成一个持续改进的飞轮？这就是“CC/CD（Continuous Calibration, Continuous Development 持续校准、持续开发）”框架的出发点。
循环的一侧是“持续开发”。你先界定能力边界，整理数据，明确系统的预期输入和预期输出。在真正动手之前，这一步本身就非常有价值，因为它常常会暴露出团队内部对“产品该如何表现”的理解并不一致。此时，产品经理和领域专家的参与尤为关键。你并不需要一个覆盖所有情况的数据集，而是一个“足够好”的起点。接下来，搭建应用，并设计评估维度。我刻意使用“评估指标”这个说法，而不是简单地说 eval，是因为评估是一种过程，而指标只是你在过程中重点关注的维度。
另一侧是“持续校准”。当系统上线后，你一定会看到大量最初未曾预料到的用户行为模式。评估指标可以帮助你发现一部分问题，但很快你会意识到，它们同样不足以覆盖所有新出现的错误模式。这时，你需要分析真实行为，识别新的错误类型，一部分问题可以直接修复，而另一部分则需要催生新的评估指标。这并不意味着每一个错误都要转化为新的 eval 维度。有些只是偶发问题，比如工具定义不清导致的调用错误，修完即可继续前进。
整体来看，这就是一个 AI 产品的典型生命周期。我们还特别强调，在迭代初期，应当采用“低自治、高控制”的方式：限制系统可做的决策数量，引入人在回路；随着理解加深，再逐步提高自治程度。这样做的本质，是在逐步建立对系统行为的认知飞轮。
以客服 Agent 为例，我们通常会把演进过程拆成三个阶段。第一阶段只是“路由”，即判断工单该被分配到哪个部门。很多人会低估这个问题的复杂度，但在大型企业里，路由往往异常困难。层级混乱、分类标准失序的情况非常普遍，人类客服往往依赖大量隐性经验才能做出判断，而这些规则通常并未被文档化。如果直接把问题丢给 Agent，而不给足上下文，风险就会非常高。在路由阶段，即便 Agent 分错了部门，人类也可以介入纠正，控制风险。同时，这个阶段往往会暴露出大量数据问题，需要优先修复。
等路由稳定之后，下一步是“副驾驶”：Agent 根据既有的标准操作流程生成回复草稿，由人工修改和确认。在这个过程中，你会自动记录人类的修改行为，从而几乎“免费”获得误差分析数据，并将其反馈到系统中。当你发现，大多数情况下人工已经不需要做太多修改时，才可以进入端到端的自动处理阶段，让 Agent 既生成回复，也完成问题的解决。这正是从低自治逐步走向高自治的过程。
我们还整理了一张表，明确每个阶段你在做什么、能学到什么，以及这些信息如何被反馈回系统。需要强调的是，采用 CC/CD 并不意味着问题会一次性被解决。即便已经走到较高版本，你仍然可能遇到此前从未见过的数据分布。这个框架的意义，在于帮助你在完全自治之前，尽可能多地理解用户行为，从而降低整体风险。
此外，它还隐含地帮你建立了一套行为日志体系。单纯依赖评估指标，只能捕捉你“已经知道”的错误，而大量新模式，只有在真实使用中才会显现出来。通过这种低风险、渐进式的方式，你可以理解用户，而不至于在问题全面爆发时手忙脚乱。最终，这一切的核心目标只有一个：在持续校准系统行为的同时，不断维护并增强用户对产品的信任。
Lenny：这套方法的核心，在于把一切都设计成持续的、可迭代的过程，沿着“自治程度不断提高、控制逐步降低”的路径前进。“持续校准、持续开发”这个命名，本身就强调了它的迭代性。顺便说明一下，这个名字显然是在向 CI/CD（持续集成、持续部署）致敬，只不过这是 AI 时代的对应版本：不再只是不断跑单元测试、频繁部署，而是持续运行 eval、观察结果、调整关注的指标，找出系统失效的地方，再不断迭代优化。
在这个框架本身上，还有没有什么你觉得特别重要、但我们还没提到的点？
Aishwarya：我们最常被问到的问题之一是：我该如何判断，系统是否已经“校准得足够好”，可以进入下一个阶段？这件事并没有一套明确的规则手册，核心原则只有一个：尽量减少“意外”。比如说，如果你每一两天就做一次校准，而发现没有出现新的数据分布模式，用户的行为也相当稳定，那你从系统中获得的新信息就已经非常有限了。这往往就是一个信号，说明你可以考虑进入下一阶段了。到了这个时候，很大程度上其实是在凭经验判断：你是否感觉自己已经“准备好了”，是否还在持续获得新的洞察。
当然，也要意识到，有些外部事件会彻底打乱原有的校准状态。比如 GPT-4.0 被弃用，API 层面逐步迁移到 GPT-5，而新模型的行为特性完全不同，这时你的校准就会再次失效，需要重新走一遍流程。用户行为本身也会随时间演化。即便是消费级产品，我们今天和 ChatGPT 的交互方式，也和两年前完全不同，一方面是模型能力提升了，另一方面是用户在某个任务上尝到甜头后，会自然地把系统用于更多新场景。
我们曾为银行的核保人员构建过一个系统。核保本身是一项非常繁琐的工作，贷款申请文件往往有三四十页。这个系统的初衷，是帮助核保人员快速查找政策和内部信息，从而更高效地审批贷款。最初三四个月，反馈都非常积极，核保人员的效率显著提升。但随后我们发现，正是因为他们对系统产生了信任，开始提出一些我们从未预料到的深度问题，比如直接把整份申请材料丢给系统，问：“像这种情况，之前的核保人员通常是怎么处理的？”
从用户角度看，这只是一个非常自然的延伸；但从产品构建角度看，底层逻辑却发生了质变。系统需要理解“类似情况”究竟指什么，再去检索历史案例、分析文档，最后给出综合判断。这已经远远超出了最初“查找某条政策”的设计范围。正是这种不断演化的用户行为，提醒你：是时候回到校准阶段，重新审视系统能力边界了。
AI 的未来
Lenny：当下 AI 领域里，哪些东西被高估了？哪些被低估了？
Kiriti：与其说“被高估”，不如说有些概念被严重误解。一个典型例子是多 Agent 系统。很多人会觉得：我有一个复杂问题，只要拆成几个子任务，分别交给不同的 Agent，再把它们连起来，就能实现所谓的“Agent 乌托邦”。现实并非如此。当然，成功的多 Agent 系统确实存在，但关键在于，你如何限制系统偏离轨道的方式。
例如，用一个监督型 Agent 来协调多个子 Agent，是一种非常成熟、有效的模式；但如果只是按功能拆分职责，期望这些 Agent 通过某种“点对点协作”自然形成整体能力，那在当前的模型能力和工程范式下，往往行不通。这并不是多 Agent 被高估，而是人们高估了它在现阶段能“自发协同”的程度。
我觉得 Coding Agent 仍然被低估了。你在 Twitter 或 Reddit 上会看到大量讨论，但你会发现它的真实渗透率依然很低，而潜在价值却极大。我认为 2026 年会是集中优化这些流程、释放巨大生产力的一段时间。
Lenny：相比预先设计一堆各司其职的 Agent，更现实的路径，可能是让一个更强的 Agent 自己完成任务拆解和协调？
Kiriti：没错。你可以由人来编排多个 Agent，也可以由一个更大的 Agent 负责统筹。但如果让多个 Agent 以点对点的方式自由通信，尤其是在客服这类对输出高度敏感的场景中，几乎不可能精细地控制“到底是哪个 Agent 在对用户说话”，护栏成本会急剧上升。
Aishwarya：我认为 eval 是被误解的概念。它当然重要，但“不断切换工具、学习新工具”这件事被高估了。我依然是比较传统的看法：真正值得投入精力的，是对你要解决的业务问题保持极度专注，AI 只是工具而已。你当然需要了解最新进展，但不要把“快速构建”本身当成目标。今天构建的成本已经非常低了，真正昂贵的是设计，是你是否真正想清楚了产品要解决什么痛点。对问题本身和产品设计的执着，是被低估的，而单纯追求“快点做出来”，是被高估的。
Lenny：从产品视角看，你们觉得未来一年 AI 会走向哪里？
Kiriti：我非常看好“后台型”或“主动型” Agent。当前 AI 难以持续创造价值，很大程度上是因为它缺乏上下文，而原因在于它还没有真正接入工作发生的地方。一旦 Agent 被更深地嵌入真实工作流，获得更丰富的上下文，它就能理解你在优化什么指标、试图完成哪些活动。接下来顺理成章的一步，就是由 Agent 主动反过来提示你。
我们已经在 ChatGPT Pulse 这样的功能中看到雏形，它每天推送一些你可能关心的更新，帮助你“唤醒思路”。把这一模式扩展到更复杂的任务中，比如 Coding Agent 在你一天开始时告诉你：“我已经帮你修复了五个工单，这是补丁，看看就行。”我认为这会在 2026 年成为非常重要的产品方向。
Aishwarya：我非常期待 2026 年的多模态体验。2025 年我们已经取得了不小进展，不只是生成能力，在理解层面也是如此。但到目前为止，LLM 仍然是最常用的模型形态，而人类本身是高度多模态的。语言其实是我们进化中相对靠后的表达方式。即便我们在对话中，也在不断接收视觉、表情、语气等信号，并据此调整表达。如果能构建真正丰富的多模态交互，将会更接近人类对话的真实复杂度。
此外，还有大量“枯燥但重要”的任务等待被自动化。如今依然有无数手写文档、杂乱的 PDF，即便是最先进的模型也难以处理。一旦多模态理解能力真正成熟，我们就能解锁大量此前无法触及的数据资源。
Lenny：如果有人想提升自己构建 AI 产品的能力，你认为最值得重点培养的一两项技能是什么？
Aishwarya：从小处着手、快速迭代、建立正向飞轮等。但如果站在更高的视角来看，对于当下的产品构建者而言，实施成本在未来几年会变得极低，真正稀缺的将是设计能力、判断力和审美品位。无论是做产品还是规划职业路径，早期几年往往专注于执行层面的技术细节，而随着 AI 大幅降低上手门槛，几年之后，每个人的价值都会更多体现在品味、判断，以及那些“只属于你”的东西上。
这种能力并不一定来自年龄或多年经验。我们最近招了一位同事，团队一直在用一款价格不菲的任务管理工具，他却直接带着自己手写的应用来开会，当场把我们全部拉进去开始用。那种主动性和主人翁意识，敢于重新思考既有体验，正是最能拉开差距的地方。当然，这类自建工具在规模化后可能有维护成本，需要替换或升级，但在小团队阶段，这种“先做出来再说”的态度让我非常震惊。很多在 AI 时代成长起来的人，对“构建”的心理成本极低，也更愿意尝试新工具。这或许也是为什么很多 AI 产品存在留存问题，大家都太容易被新工具吸引了。
归根结底，真正重要的是主动性和责任感。“忙碌但无效”的工作时代正在结束，你不可能再躲在角落里做对公司没有实质影响的事，而必须思考端到端的流程，以及如何创造更大的影响。
Lenny：这让我想到我之前请过 Jason Lemkin 上节目。他把整个销售团队几乎都替换成了 Agent：原来 10 个销售，现在是 2 个人加 20 个 Agent。结果有位销售直接辞职了，因为他发现自己“什么都没干”，很快就会被系统识别出来。这也印证了你的观点——混日子会越来越难。
Kiriti：坚持和承受“痛苦”的能力同样被严重低估。如今信息触手可及，几乎任何人都可以在极短时间内学习新东西，但真正的差别在于，是否愿意经历反复试错的过程——学习、实现、失败、再调整，真正理解什么有效、什么无效。我常说“痛苦是新的护城河”，这种在实践中积累的经验，无论对个人还是公司，都会沉淀为难以复制的优势。
很多成功的公司，并不是因为抢先进入市场，或拥有多么炫目的功能，而是因为他们经历了足够多的痛苦，搞清楚哪些是不可妥协的核心点，并在模型能力、功能取舍之间不断权衡。这没有标准答案，也没有教科书，只能靠一轮又一轮的迭代。正是这些过程中的“痛苦”，最终塑造了个人能力和公司的长期竞争力。
Aishwarya：专注于问题本身。AI 只是工具，关键在于你是否真正理解自己的工作流。很多所谓的 AI 工程师和 AIPM，把大部分时间花在理解业务流程、用户行为和数据上，而不是追逐最炫的模型。真正的差异化，永远来自对用户和问题的深度理解。
闪电问答
Lenny：你们最常推荐的书是什么？
Aishwarya：《当呼吸化为空气》。作者 Paul Kalanithi 是一位神经外科医生，在三十出头被诊断出肺癌。这本书让我意识到，我们是否花太多时间“评估人生”，却忘了真正去生活。
Kiriti：我更偏爱科幻，《三体》三部曲。它不仅讨论外星文明，也深入探讨科学、地缘政治与人类决策，对理解技术与文明的关系非常有启发。
Lenny：如果喜欢科幻和 AI，我还强烈推荐《深渊上的火》（A Fire Upon the Deep）。
Lenny：最近最喜欢的影视作品？
Aishwarya：我在重刷《硅谷》，它出奇地不过时，如今的 AI 浪潮和当年的情景高度相似。
Kiriti：我选一个游戏，《Expedition 33》。制作精良，故事、音乐和玩法都非常出色。
Lenny：最近发现并非常喜欢的一款产品？
Aishwarya：Whisper Flow。我没想到自己会这么依赖它，它能把语音自然地转化为指令，体验非常顺滑。
Kiriti：我偏好效率工具，比如 Raycast 和 caffeinate，让我在本地跑长时间任务时效率更高。
Lenny：你的人生信条？
Aishwarya：“人们说这件事做不到，但那个傻子不知道，于是他做成了。”在这个数据随时告诉你“你大概率会失败”的时代，保留一点愚蠢的勇气很重要。
Kiriti：乔布斯那句话：你只能回头看时，才能把点连成线。所以不断前进、持续尝试就好。
Lenny：你最欣赏对方的一点是什么？
Aishwarya：Kiriti 非常冷静、踏实，是我最重要的“回声板”，而且他是我见过最好的丈夫。
Kiriti：Aishwarya 最大的特点是，她能把复杂问题讲得极其清楚，并且始终保持耐心和坚持，这在快速变化的 AI 时代非常珍贵。
参考链接：https://www.youtube.com/watch?v=z7T1pCxgvlA
