第六课　AI越会写代码，越要克制“一次性做掉”的冲动

同一个产品，进每家公司都要重新学习

客户服务Agent不是换一个公司Logo就能上线。它要学习品牌语气，知道哪些用户意图可以自动处理，哪些必须转给人；要连接认证、订单、会员、账单等后台系统，才能真正替用户修改信息或发起退款。

传统客服的用户体验很容易辨认：打电话后在语音菜单里“按1查账单、按2改会员”，发邮件后等待两三个工作日。Decagon要替换的不是一个问答框，而是这整段交互。用户通过电话、邮件、短信或其他渠道接入后，应当直接遇到一个能够理解自然语言、保持品牌语气，并且有权限完成动作的Agent。

“完成动作”让部署难度骤然上升。回答“退货政策是多少天”只需要找到正确知识；真正办理退货还要确认身份、读取订单状态、检查商品和时间是否符合政策、调用后台接口、把结果写回客服系统，必要时完整移交给人工。每一家企业的政策、系统和风险边界不同，所以底层Agent平台可以相同，进入生产前的学习却不能省略。

Decagon的forward deployment因此有两类工作。

第一类是让Agent的大脑适应这家企业：写清政策、工具、转人工规则、渠道与成功指标。尽可能通过产品界面和自然语言配置完成。

这里的“大脑配置”至少包含四层：Agent知道什么，即知识与政策；Agent能做什么，即可调用的工具与权限；Agent怎样表达，即文字语气、语音风格和品牌规范；Agent何时停下，即转人工和风险升级规则。训练一名人类客服时，这些内容会散落在手册、跟岗和主管反馈里；训练Agent时，它们必须变成可测试、可版本化的系统配置。

第二类是把现场需求变成产品能力：客户A提出一个功能时，FDE要预判客户B、C、D是否很快也会需要。不是为A写一段孤立补丁，而是让后来的客户还没提出请求就已经得到能力。

Rekhi甚至说，在Decagon，FDE与产品工程使用同一工程门槛、同一汇报体系，常常就是同一支团队。面对一家大型企业的痛点，现场请求与产品路线图之间没有清晰墙壁。

这和客户结构有关。中型品牌的需求可能通过现有配置解决；《财富》美国500强排名最前的20家公司，通常被简称为Fortune 20，一家这种规模的企业提出的问题却常常暴露平台层缺口。这里强调的是客户规模和复杂度，而不是一种技术分类。这类客户常带来新的安全模型、跨区域治理、特殊渠道或大规模运行能力。现场工程师若没有修改核心产品的能力，只能在外围不断增加补丁；产品工程师若不接触这些现场事实，也很难提前理解企业级要求。

从一个人全包，到两条专业化通道

公司规模较小时，Agent Software Engineer可以包办一切：与客户并肩配置Agent、连接后台、处理产品缺口。客户不多，这种英雄式模式能够运行。

当公司只有约50人时，同一个工程师了解客户、调提示、接接口、补产品功能，信息几乎不需要跨团队传递。速度很快，问题也能靠少数熟练者的记忆解决。但一年内增长到约500人之后，原来的优势会反过来成为风险：客户数量、行业跨度和内部协作同时扩大，没有人还能独自掌握全部上下文。

高速增长之后，瓶颈出现了。Decagon把工作分成两条通道：

• Agent Builder：熟悉不同模型的行为和Decagon平台，主要在界面内配置、测试和优化Agent；
• Agent Software Engineer：解决需要代码和平台变化的问题，把企业请求上游化为产品。

专业化不是重新筑墙。Agent Builder遇到界面无法处理的问题，要把它送入产品；Agent Software Engineer每次写代码，都要问怎样让Builder、客户或Agent自己完成下一次相似工作。

Agent Builder并不是“技术要求较低的实施人员”。他们要理解不同模型的行为，知道怎样在自然语言指令、知识、工具和评测之间定位问题，尽量在产品界面内完成配置；一旦发现必须写代码，真正重要的输出不是一张临时工单，而是清楚说明平台为什么表达不了这个需求。Agent Software Engineer则从这些缺口里寻找通用设计，让前线下一次不必再离开界面。

两条通道的协作质量，可以用一个简单问题检验：同类需求第二次出现时，交付方式有没有改变？如果第二个客户仍然需要同样的核心工程师、同样的私有脚本和同样的手工排障，组织虽然分了工，却没有形成扩张能力。

代码便宜之后，最贵的是克制

一个重要客户提出需求，工程师现在很容易让编码Agent迅速写出定制实现。这种诱惑比过去更强：既然一小时能做，为什么不做？

过去，一次性功能至少会受到开发成本约束。需要排期、写代码和测试，团队会被迫讨论它是否值得。编码Agent把第一版成本压得很低，也拿掉了这层天然阻力。工程师可能在等待产品评审之前就把补丁做完，而“代码已经有了”又会成为上线理由。生成速度因而会系统性地推动过度定制。

Rekhi的回答是，因为一次性方案的真实成本不在第一小时，而在未来。提示词、特殊分支和补丁会叠成黑箱；客户无法理解和拥有自己的Agent；下一个客户仍要重做；每次模型或平台更新都可能破坏隐藏依赖。

因此，AI编码时代的稀缺技能不是生成，而是“克制与远见”：这项需求会怎样扩展？应该成为配置、接口还是核心能力？一年后客户还能看懂吗？

Decagon强调客户应当拥有自己的Agent。这里的“拥有”不仅是合同上的控制权，也意味着客户能看懂行为从哪里来，能在政策变化时自行修改，并能追踪某次决策依据。若Agent由大量隐藏提示、客户专属分支和没人敢动的补丁构成，供应商看似迅速满足了请求，实际上把客户锁进一个脆弱黑箱。克制就是拒绝这种短期便利。

Decagon官方在会前发布的文章也给出相同方向：forward deployment若要扩张，不能只依靠嵌入现场、什么都能做的英雄人物，而要把交付本身当作系统设计，让一次手工工作变成下一位客户不必重复的能力。

先把“成功”写下来

面对大型企业，团队很容易急着开工。Decagon的教训是，最早几次对话就要把成功标准写清：客户要支持哪些渠道？想改善哪种意图？转人工率、解决率、响应时间、客户满意度或收入目标分别是什么？哪些情况不在第一阶段？

渠道本身也会改变问题。同一个“修改预订”，在邮件里可以等待几分钟并请求补充信息，在实时语音里则要控制沉默、确认用户身份并处理口音；消息应用WhatsApp可能要求短消息和异步恢复。若合同只写“上线客服Agent”，供应商可能完成了邮件，客户却在等待电话；双方都能拿出证据证明自己理解正确。把渠道、意图和指标写在最初的成功定义里，是避免这种错位的最低成本做法。

书面标准能防止双方在几个月后发现，供应商以为“Agent已上线”，客户却以为“所有客服都应被替代”。它也给评测提供了靶子：没有成功定义，就无法判断Agent是在创造价值，还是仅仅处理更多对话。

行业知识会复利

当客户跨金融、旅行、科技等行业，通用FDE每次都要重新学习监管、术语和常见流程。Decagon开始把有行业经验的人配置给同类客户。知识不仅帮助建立可信度，也缩短需求发现：金融客户D出现时，团队已经知道A、B、C反复遇到的边缘情况。

垂直化的价值不只是“会说行业黑话”。熟悉金融服务的人知道哪些动作通常需要强认证，哪些解释必须保留审计证据；熟悉旅行的人知道行程变更会牵动库存、付款和合作伙伴。团队因而能更早提出客户尚未想到的问题，也能区分行业共性与单家公司特例。

当然，横向经验也可能变成偏见。FDE不能因为前三家金融客户使用同一种流程，就假定第四家必然相同。成熟的行业知识更像一组高质量假设和检查表：帮助团队加速提问，而不是替代现场验证。

这使“每次部署都比上次快”成为可测目标。速度不只来自更熟练的人，还来自三种积累：垂直知识、产品自助能力和跨部署共享的评测数据。

先证明价值，再扩大边界

大型客户常在第一天就带来“整个厨房”：多渠道、复杂意图、所有集成、全球语言和严格治理。Decagon选择先找到能迅速证明价值的一小段工作，上线后再扩展到整个支持流程和收入场景。

例如，一家租车公司最初可能只想自动处理复杂的入站支持；Agent已经连接后台并与用户建立关系后，又可以主动提醒续租或延期，把支持入口扩展成收入触点。演讲以租车公司Hertz说明“land and expand（先落地、再扩张）”：先赢得一个可验证结果，再利用已经建立的数据、信任和连接扩大边界。

Rekhi对Hertz案例的描述正体现了这种顺序。Decagon先进入复杂的入站支持流程，已经拥有与租赁后台系统的连接，也理解客户状态。团队随后发现，同样的基础设施可以用于主动沟通：在租期即将结束时联系客户，询问是否续租或延长。客服Agent由成本中心里的自动化工具，扩展成可能创造收入的客户触点。

但扩张不能成为第一阶段无边界的借口。《财富》按营业收入排列的美国500家大型公司，即Fortune 500，往往会一次提出所有渠道、语言、意图和集成，Rekhi称之为把“整个厨房”都扔过来。FDE要从中找出最短的价值证明，在数周而不是数月内让一组真实用户得到结果。建立信任之后，再沿着已验证的路径扩大覆盖。

顾问，而不只是执行者

客户说“先自动化X”，FDE不必总照做。Decagon会分析历史支持数据，判断哪类请求量大、自动化可行且回报高，再建议先做另一项。因为FDE同时看过多家企业，它拥有单个客户看不到的横向经验。

历史支持数据可以把争论变成排序问题。某类请求数量很大，却需要高风险判断，不一定适合第一阶段；另一类数量稍小，但流程稳定、后台动作清楚，可能更快形成自动解决。FDE要把业务影响、技术可行性、风险和上线速度放在一起，而不是只选择呼声最高的团队。

这并不授权供应商替客户决定一切。它要求FDE同时做执行者和顾问：尊重业务目标，又能用数据挑战方案；快速交付，又把每次手工动作送入产品漏斗。

Decagon早期曾为不同客户反复手写客户关系管理系统（CRM）集成。CRM保存客户身份、联系、销售与服务记录；客服Agent若要完整交接或写回处理结果，往往必须连接它。大约做到第二十五个时，团队意识到继续复制已经没有意义，于是把连接能力改造成自助方式。原本必须由工程师写代码的工作，后来可由Agent Builder甚至客户完成。这个过程说明custom-to-self-serve不是一句原则，而是一笔可以追踪的账：某个手工动作出现了多少次，消耗多少工程时间，抽象之后又让多少部署变快。

自然语言配置是Decagon给这条漏斗设定的方向。如果一项Agent行为仍必须由工程师进入代码修改，团队就应问它能否上游化到产品，让业务人员以自然语言表达规则，同时由平台提供版本、测试和护栏。并非所有复杂性都能消失，但工程师介入应当成为发现产品缺口的信号，而不是永久交付方式。

从现场定制到产品自助的漏斗

产品化不能只凭“很多客户都提过”来判断。团队还需要知道现场问题是否真的影响结果，修复之后是否带来可测改善。下一课把客户部署当作一组高保真评测，区分Agent跑了多少与企业实际完成了什么。