即刻App年轻人的同好社区
下载
App内打开
一碗小面
211关注364被关注3夸夸
即刻街溜子
经常反思“为什么”
置顶
一碗小面
2年前
你就尽管做自己。
40
一碗小面
00:05
因为独立做过新渠道，team没人，处理投诉一度占到我每天1/3的时间，极端的case基本上2天时间都放在一件事上，还是在有服务质量同事过滤的情况下。
这么说是想分享给各位，买机票投诉这事儿确实有效，甚至可能是少有的非常受重视的一类投诉，尤其是找对了途径，轻松就能把一个我这样脾气不好的业务搞生气。
但你为了省个自愿退票费说自己死了或者得了什么不治之症这种事儿是人能干出来的吗？
btw，已积攒大量识别假病历经验，甚至丝滑运用到了一起员工伪造病历恶意仲裁事件上。

_判官_: 有没有可能，这个医院证明，也是他从闲鱼买的

00
一碗小面
3天前
巴威对杭州实际的影响 be like👇
40
一碗小面
5天前
有即友找我买海航天价卡嘛
预存66666，境内1500+航线一口价379。每年两次机会可以换绑定人，赠送积分可兑换机票等权益给其他人使用。
燃油附加费持续下调，会通过涨机票票面价去平衡，飞得多379不会亏
00
一碗小面
7天前
解药比毒药贵，因为知识溢价！
00
一碗小面
7天前
今年频繁想起林奕含采访里的一个问题：“我想要叩问的是，文字是否有巧言令色的成分？”。频繁想起是因为频繁遇到了想回答的时刻，“有，而且不低。”
00
一碗小面
8天前
在这场股东纠纷里最难过和说服不了自己的点，不在于经常被知情人提醒我好像要因为无知被全世界同情，也不是一些应该事前做的我因为缺少经验而是现在在补足，而是我在反复质问自己，就这样的货色，到底哪里值得我出钱出力和信任能把这小业务做大做强了？一开始不对劲的时候就该否定，而不是还在矫情的给对方找借口和设置1.2.3条件，都满足了再跳出来质疑。
01
一碗小面
9天前
城市里的蚊子是进化了吗！
在杭州被咬一周多还没好，甚至颜色还变深了，去天台山被咬第二天就没啥感觉了
20
一碗小面
12天前
好像很多人压根区分不了品牌/媒介/市场🤣
哦，再加一个运营
21
一碗小面
12天前
一知半解的看完了，不懂的地方打算过几天翻出来再看看。

Bink_Ron: 近两年，我主要的产品命题是：做 Voice Agent（AI电话 agent，完成各种带 SOP 的呼叫任务） 的产品设计，当然还包括评测。Voice Agent 设计是一个比较独特的产品命题，因为它的关键约束和主航道agent（比如 chatbot、coding agent、情感陪伴 agent） 都不太一样。 在这件事情上，有一些阶段性的成果和思考，在这里分享一下，如果有可能，也希望能跟有 Agent 实战经验的同学交流，思考交换思考～ --- 构建 AI 电话 Agent 的早期，我们面对的第一个问题不是"用什么框架"，而是一件更扫兴的事：我们必须先承认，这个场景里，既无法使用 SOTA 模型**，也开不了长推理**。 原因是一道几乎无法谈判的物理约束。在real-time的语音通话过程中，用户能容忍的延时大约 1.5 到 2 秒，而"听-想-说"的级联pipeline*里，“听”的部分（ASR 加 VAD）差不多需要花费 600 到 800 毫秒，“说”的部分（TTS ）再拿走 300 毫秒——留给 Agent "想"的窗口，至多 1 秒。这个约束下，使用 SOTA 模型是不可能了，推理太慢；长 CoT推理也被限制了。 （*注：出于 private 部署、SOP 强控制、优化成本、可定制性等方面要求的综合约束，E2E乃至两阶段方案均无法满足产品需求，因而使用传统的级联架构） 这个非主流的命题意味着，很多著名的 Agent 设计实践在这个命题下可能都不能成立。 1️⃣ Less structure, more intelligence？ Manus 的 Hidecloud 曾提到了Manus 的设计理念：“Less structure, more intelligence”。Peak 在25年7月的 blog 中也写到： > 如果模型进步是上涨的潮水，我们希望Manus成为那条船，而不是固定在海床上的柱子。 > 这个浪漫判断的前提是模型的进步。当前范式下，模型进步的主路径无非两种情况：要么是 scaling law的暴力美学，要么是RL 带来的推理能力提升。但这些进步的大潮，在1秒的输出时间约束下，似乎无法冲击到我们的小河。 LLM 推理的过程中大致上会遵循一个公式： > **单次推理中：[同时要做的判断数] × [每个判断的复杂度] < [LLM 在 1 秒内能输出的智能上限]** > 由此看，如果要让 LLM 正常工作，从数学上看只有三条路：**砍判断的数量、砍每个判断的复杂度、或者榨干那一秒里的智能上限**。 如果使用 less structure，也就是围绕着LLM 搭建结构，公式的右边的上限几乎是被锁死的，要么就只能靠自己。那么大部分工作只能围绕着左边做。 而如果这么选择你大概率会发现，左边的事情并不是我们所能决定的，如果客户提出了诸多要求，我们没有有效的机制来满足，客户就会流失。 事实证明，左侧能做的一切，就是 context engineering 。我们可以给模型提供各种外挂，比如 RAG，校验工具，计数器等，我们可以优化 prompt 结构，让指令更加清晰。但由于右侧的限制，一定会在复杂度达到某一个阈值后崩溃，出现幻觉、重复、甚至答非所问的现象。 2️⃣ Multi-agents？ 2025年年中的一个热门话题是：到底是 single agent 架构好，还是Multi agents架构好。Cognition （Devin 的母公司）曾在 blog 里认为，绝大多数任务 Multi agents 反而是累赘；Anthropic 近乎是同时间发布了一篇 blog（https://www.anthropic.com/engineering/multi-agent-research-system），说 Multi agents 在Claude 的 deep research 任务上运转非常良好，他们提出了 leader+subagent 架构。 实际上，我们的电话智能体在24年设计之初就选择了 Multi agent 架构。我们认为，AI 电话过程，本质上是一个 SOP 执行的问题，而 SOP 的执行，核心是状态的管理和子流程的执行，具体是四个问题的决策： > 谁拥有状态地图？谁来上报状态？谁执行状态转移？谁来完成当前环节的应对？ > 我们已知 LLM 的一次调用干不了这四件事情，那么自然想到分解事情。分解有两种思路： 1. 横向拆——分解流程：将状态地图切成若干节，每次只将一节给 LLM 看，简化任务，但事情还是都给 LLM 做。 2. 纵向拆——分解职能：把这件复杂的事情拆开，分给 LLM(s)、代码规则一起来协作，简化 LLM 分到的任务。 当然，也可以两种思路结合，既分解掉流程，又分解职能。我们在最开始就选择了最复杂的思路，分解流程+分解职能。我们设计了一个路由模型专门负责状态的转移，一个话术模型专门负责当前环节的应对，后来发现状态转移这件事情还比较复杂，又加了一个 NER 模型来提取中间状态。 Multi agents 如果用好了是蜜糖，用不好则是砒霜。我们感受了一下这砒霜，这是协作问题的苦果。 协作问题体现在，假设SOP 中的某个环节要求收集用户的一组信息，这件事需要三个模型接力：话术模型负责播报问句和生成回复；NER 负责从用户的表述里判断该不该抽取，抽取值是什么；路由模型根据信息收集的情况判断是否流转状态、流转到哪个节点。系统的正常运转依赖三个模型配合良好，一旦有一个模型出问题，系统就会因为木桶的短板效应而漏水。比如： > 路由模型依赖NER结果跳转，NER依赖话术播报，如果NER 和话术播报的标准无法对齐，NER 提前更新 slot状态或不更新，路由要么提早跳出，要么跳不出。如果是跳不出，就会陷入到死循环——NER 死活不收集，因为话术模型没有播报确认话术；话术模型不知道自己要播报这句话；路由没看到 NER 结果，一直不跳转。用户感知到的就是，客服一直在重复，或者胡说八道。 > 类似case越来越多后，我们做了一次对架构的反思：Why multi agents？ 复杂的设计都是从简单的设计演化而来的，当发现简单设计无法满足需求时，才开始设计更精妙的结构。但如果连简单设计会遇到什么问题都不知道，一上来就跟随潮流，选择复杂架构，大概率是无法驾驭好它的。奥卡姆剃刀定律：如无必要，勿增实体。 想清楚了这个之后，我开始尝试，从最简单的single agent + 外挂（RAG、Hook等）开始，面向业务问题进行架构和 prompt 设计。当复杂到single agent 用prompt engineering无法处理后，我们再加入状态管理机制的设计，将流程分解出来，每次只给agent看当前节点以及下游可达的edge及其到达条件，agent一次调用输出话术+ node ID的决策。在必要的时候，主动调用需要的工具。 我们发现，single agent 在加入状态管理后，上限已经非常高了，超出了我们的预想，还规避了此前multi agents的各种协作问题，综合表现超越之前架构。 但后面随着更复杂的任务场景的出现，我们意识到，在1秒的约束下，如果任务足够复杂，迫使系统要输出尽可能高的智能，multi agents 协作设计几乎是避不开的工作。 因为AI电话这件事情的本质，就是将非标准化的沟通上下文与用户表达、和非标准化的SOP设定进行匹配，即：理解SOP、理解上下文并将SOP设定转化成话术输出。 这些理解和输出的工作几乎只有LLM能完成，在有限的时间内、智能输出密度锁死的情况下，要想有更高的智能，设计精妙的协作结构，用空间换时间几乎是无法避免的。 3️⃣ 空间换时间的思考 在1秒的限制下，要如何设计 pipeline 结构，才能在有限的时间内充分利用空间，榨取更高的智能？这里可以分享的是一些底层的思考。 【思考1】LLM 只做其不可替代的工作 LLM 作为一个涌现范式的造物，最大的魅力在于其近乎无穷的variety，这使它成为了通用的智能。任何凌驾于其上方的规则都是对它的枷锁，是对智能的亵渎。因此，“Less structure” 这样简单粗暴的原则，在思考预算充足、模型足够聪明时，是优雅的。 但当智能本身被时间这把枷锁束缚，且还要求系统输出尽可能高的智能时，这条原则便不再适用。题目成了一道冷酷的分配优化题，需要精打细算，把算力花在最应该花的地方。 仔细盘点一下，一次问答里要做的事，其实可以干净地被分成两类： - 一类是**有确定性规则的，**比如现在该不该转移到下一个节点、用户拒绝到第几次了、同时触发了投诉和应答该听谁的。这类判断要的是全局信息(完整的流程图、所有槽位的值、一套优先级)，而且答案是唯一的、可以查表算出来的。 - 另一类是**语义性**的，比如用户这句模糊的话到底是什么意思、该用哪句话回应。这类判断要的是对自然语言的理解，是模糊匹配。 这两类判断，卡在一条天然的断层线两侧： | | 确定性判断(导航) | 语义判断(应答) | | --- | --- | --- | | 需要的信息 | 全局(拓扑、全状态) | 局部(当前上下文) | | 答案性质 | 唯一，可查表 | 模糊，需理解 | | 谁来做最合适 | 代码(快、无幻觉) | LLM(几乎无法替代) | 此前 single agent 方案，LLM有大量的计算需要花在确定性判断上，而这些 LLM 并不是最擅长的，也不必须。 **试着把所有确定性的判断——状态转移、计数、仲裁——整个交给代码；LLM 只做两件它唯一擅长的事：根据 SOP 输出交互话术，上报状态转移依赖的前置观测结果。至于这个观测意味着流程该走向哪里，是代码拿着全局拓扑去算的。模型负责观测，代码负责导航。** **用代码把所有确定性的活全部接走，好让那一秒里稀缺的智能密度，百分之百地用在最值得的地方——语义理解上。** 空间(代码承载的确定性结构)换来的，是智能的浓度。 但此时LLM 手里还攥着两件事：出话术，和上报观测。由于这依旧是两个方向上的能力，在最复杂的任务中，LLM 依旧会陷入瓶颈，引起幻觉。还需要想办法增加冗余，怎么做？ 【思考2】隐藏在枷锁之外的智能 先回到开头那道延时的账：ASR 和 VAD 吃掉 600 到 800 毫秒，TTS 再拿走 300 毫秒，留给"想"的不到1秒。但是，但是，这1 秒约束的，只是用户听到的第一个字（或"首 token"），而非"总算力"。 换句话说，话术，产出的是要立刻送进用户耳朵的 token，它必须快。可观测不一样：它产出的只是个喂给代码去导航的控制信号，而这个信号真正被用上，是在**下一轮**——它不产出任何用户当下听得见的东西。既然如此，它的约束其实变宽了很多，它可以慢下来。一旦看清这一点，会发现，两道枷锁——禁用超大模型、禁止长推理——**同时对后者**松开。 这里面可以做非常多事情，来释放系统的智能冗余。 【思考3】长未必复杂，矛盾一定造成复杂 复盘曾经 Multi agents 的失败模式，我们发现，single agent 中，LLM prompt 封装后的长度，是此前 any of multi-agents 的几倍长，但依旧表现出了更高的正确概率。 “Context , not control” 是根本原因。 single agent 的设计中，我们给出了清晰的 context 和自主性。体现在： - 配置了的工具和知识允许 agent 必要时自主调用； - 外挂的系统知识通通都交代了来路，暴露出了置信度风险； - 不仅仅是最终话术的输出，而是包含过程输出也披露在对话历史中了。 这样一来，模型拿到的信息是完整、自洽的，目标是什么、策略是什么、参考信息有哪些、工具有哪些等，这些被工整的喂给模型，剩下的交由模型来判断。模型的潜力得到充分的释放。 相比之下，曾经Multi agent 协作的失败，源于直接决定输出质量的判断，分散在多个模型里，且相互之间还有所交叠，一旦交叠的信息出现冲突，注入到 LLM 的 prompt 就是灾难性的，在有限的思考时间里，LLM 很难消化这种信息矛盾带来的复杂度，决策失误的概率因此增加。这种接力式的协作结构必然遵循短板效应——只要一个环节拉跨，输出就会拉跨。 虽然现在都在提 Harness，但 Harness Engineering 只是把事情写宽了，Context Engineering 作为 Harness 设计的重要组成部分，始终不会过时。 【最后】 我有一种感受，在模型能力还未触及天花板的今天，用“Less structure”的设计哲学来探索模型在通用型任务上的天花板是明智的，没有一种预设的框架，能应对真实世界近乎无穷的 variety。设定好 harness 框架，给足 context 和 permission，是释放模型潜力的钥匙。 但是，并非所有任务都需要或应该这样做。不同生产环境、不同生产环节，要面对的命题和约束多样性大到无法穷举，大多数任务用不上也无需用上 SOTA 模型和max effort 推理。换句话说，即便是模型未来不再进步，现有的各种规格、特点各异的模型，也依旧能被利用起来，设计出符合各个生产命题和约束要求的组件，带来生产力的提升。 就像是内燃机、电机技术发展到今天，并不是所有场景都追求最大的排量、最高的转速一样，不同需求场景、约束带来了极具多样性的设计。 回头看，我们做的大多数判断，还是基于那几个老问题：目标和关键约束到底是什么，核心问题到底是什么，什么样的结构和框架能 work，怎么论证… 这些古典产品经理擅长的思维方式，在大模型时代依旧适用。

00
一碗小面
13天前
一边吃酸菜鱼一边（被迫）听隔壁桌两个女生聊恋爱史。全是对前男友的各种不满意和相处下来的不舒服，两个人也都说自己那时候因为各种各样的原因会抵触和外界的沟通。
然后，转折来了，随着抨击的事情逐渐变多和时间轴逐渐统一，发现原来两个人是同一个男生的不同任女友。
前任火锅局，挺新鲜，恋爱史当下酒菜了。
20