AI Agent Harness Engineering 的商业化困局：按 Token 计费还是按结果付费？

AI Agent Harness Engineering 的商业化困局按 Token 计费还是按结果付费引入与连接为什么今天要讨论这个「不是选择题的选择题」核心概念AI Agent Harness Engineering下文简称「AH工程」、商业化困局前置假设、按结果付费的「AI经济新契约」幻觉与现实锚点、按Token计费的「延续性陷阱」与路径依赖机制0.1 一个凌晨四点的故事从CTO的崩溃开始凌晨四点的深圳南山科技园某垂直电商SAAS公司的「智能客服AH工程专项」会议室灯光亮得刺眼——上周刚上线的AH集群覆盖售前导购、售后退换、物流追踪、投诉转人工前置过滤全链路不仅没完成PM设定的「首月转人工率降30%、NPS升15%」KPI成本还炸了锅单月API Token调用量超预期1200%超出季度AI采购预算270%客服总监拍桌子说转人工前置过滤只敢用传统规则引擎兜底「一不留神GPT-4 Turbo就把退货地址写成供应商总部、把满减活动说成去年双11的过期版本今天已经收到37条工商投诉举报的‘苗头线索’——用户把我们客服喊成‘瞎指挥的AI幽灵’」PM翻着系统日志指着一行「Token消耗异常日志」委屈巴巴「明明是AH开发者把‘每轮对话允许调用的工具链数量从3个放宽到7个’才导致的转差率低成本高可现在CTO说要么裁掉AH专项团队的一半要么和OpenAI/智谱重新谈计费——但谈来谈去对方只愿意降单Token调用的阶梯价百万级调用打7折千万级打6折亿级才有资格谈SLA和5折我们哪敢烧到亿级」更崩溃的是创始人凌晨四点发的群消息「上个月拿到的A轮追加轮本来有40%要砸AH工程的全链路升级现在投资人只给10%还要求「三个月内拿出可复制的、ROI2的AH工程商业化方案——要么客户愿意按我们承诺的「转人工率降幅客单价提升」付费要么我们自己把AH工程的运营成本控制在传统规则引擎的1.5倍以内」你看这就是今天无数AH工程从业者、SAAS公司创始人、垂直行业数字化负责人共同面临的**「凌晨四点困境」——它不是「技术做不出来」的问题今天GitHub上有10000个开源AH框架比如AutoGPT、LangGraph、LangChain、AutoGen随便拉个5人左右的AI业务团队三个月就能堆出一个覆盖特定场景的AH集群原型也不是「客户要不要」的问题几乎所有垂直行业的数字化决策者都把「AH工程落地」写进了202X-202Y年的核心战略规划比如零售的「智能选品AH智能复购AH智能供应链调度AH」、金融的「智能投研AH智能合规审查AH智能财富管理助理AH」、医疗的「智能病历整理AH智能辅助诊断前置提示AH智能用药提醒与随访AH」、教育的「智能个性化学习路径规划AH智能作业批改AH智能答疑前置引导AH」、制造业的「智能设备预测性维护AH智能生产流程优化AH智能质量检测前置提示AH」而是「技术落地后怎么赚钱、怎么控制成本、怎么给客户一个明确的‘花钱的理由和结果的预期’」**的问题——这个问题的核心矛盾就是今天这篇技术博客要拆解的「按Token计费还是按结果付费」。0.2 你以为你懂但可能真的不懂先澄清几个「假常识」在正式开始拆解这个困局之前我们必须先澄清几个AH工程领域和商业化领域里流传最广的「假常识」——这些假常识就像「雾霾」一样遮挡了我们看清困局本质的视线假常识1「AH工程就是大语言模型LLM工具链记忆模块的简单拼接」很多人——包括一些入门级的AI开发者、PM、甚至垂直行业的数字化负责人——都认为AH工程就是「把LLM当大脑把搜索API/数据库API/代码执行API/文档处理API当手脚把向量数据库当长期记忆把上下文窗口当短期记忆然后拼在一起就能解决所有问题」。但实际上AH工程的核心不是「拼接」而是「Harness驾驭/约束」——这个词的英文原意是「给马套上笼头和缰绳让马按照人的意志奔跑同时不能脱缰、不能踢人、不能累垮」。放在AI Agent领域「Harness」的意思是约束大语言模型的幻觉让Agent在调用工具链、生成决策、回答用户问题的时候必须基于「可验证的事实数据」比如企业内部的知识库、外部的权威数据接口、历史对话的真实记录而不能基于「大语言模型的参数统计猜测」约束大语言模型的成本让Agent在每轮对话、每次任务执行过程中尽可能少调用「高成本的大模型API」尽可能多调用「低成本的传统规则引擎、向量语义匹配、轻量级微调小模型API」同时还要保证「任务完成的质量不会下降太多」约束大语言模型的行为边界让Agent只能调用「企业授权范围内的工具链」只能访问「企业授权范围内的知识库和数据接口」只能生成「符合企业价值观、合规要求、业务规范」的决策和回答约束大语言模型的任务路径让Agent在执行复杂任务的时候能够按照「企业预设的最优任务路径」或者Agent自己通过强化学习、路径规划算法学习到的「次优但可接受的任务路径」去执行而不能「漫无目的地调用工具链、浪费Token、浪费时间」监控大语言模型的执行过程让企业能够实时监控Agent的「每一步决策、每一次工具调用、每一条生成的内容、每一次任务完成的质量和时间」一旦发现「幻觉、超权调用、违规内容、任务失败、成本异常」能够「立即停止Agent的执行、立即转人工干预、立即回溯错误原因」迭代大语言模型的Harness规则让企业能够根据「Agent的执行日志、用户的反馈、业务的变化、合规的要求」快速迭代「约束幻觉的规则、约束成本的规则、约束行为边界的规则、约束任务路径的规则、监控告警的规则」甚至能够「微调轻量级小模型、优化向量语义匹配的算法、调整工具链的调用优先级」让Agent的「执行质量越来越高、执行成本越来越低、执行效率越来越快」。简单来说AH工程就是一套「针对AI Agent的、全生命周期的、可监控可迭代的管理系统」——它的核心价值不是「让Agent能做什么」而是「让Agent能安全、可控、低成本、可预期地做什么」。假常识2「按结果付费是AH工程商业化的唯一正确方向」很多垂直行业的数字化决策者、甚至一些AH工程的创业者——包括AutoGPT的创始人Shane Legg哦不对Shane Legg是DeepMind的联合创始人AutoGPT的创始人是Toran Bruce Richards——都认为「按结果付费是AH工程商业化的唯一正确方向」因为「按结果付费符合‘用户为价值付费而不是为手段付费’的商业逻辑能够消除用户的‘试错成本焦虑’能够让AH工程的价值‘显性化、可量化’」。但实际上按结果付费对于AH工程来说是一个「听起来很美但做起来很难甚至在很多场景下根本不可能」的「幻觉」——我们后面会在「深度层」和「多维透视层」详细拆解这个幻觉的现实锚点在哪里、为什么做起来很难、哪些场景下根本不可能。假常识3「按Token计费是传统云服务的‘延续性陷阱’必须尽快抛弃」很多AH工程的创业者、甚至一些AI领域的投资人——包括红杉资本中国基金的沈南鹏哦不对沈南鹏已经退休了红杉资本中国基金现在的管理合伙人是周逵、计越、孙谦、刘星等人——都认为「按Token计费是传统云服务比如AWS EC2按CPU时长计费、AWS S3按存储空间和流量计费、OpenAI早期的GPT-3按API调用次数计费的‘延续性陷阱’必须尽快抛弃」因为「按Token计费不能反映AH工程的真实价值——比如一个Agent用1000个Token完成了一个能为客户创造100万元价值的任务另一个Agent用10万个Token完成了一个能为客户创造1000元价值的任务按Token计费的话前者的收入只有后者的1%但前者创造的价值是后者的1000倍这显然是不公平的」。但实际上按Token计费对于AH工程来说是一个「虽然有缺陷但在今天的技术条件和市场条件下最可行、最容易落地、最容易和客户、云服务商、AI大模型厂商建立信任关系」的「现实锚点」——我们后面也会在「深度层」和「多维透视层」详细拆解这个现实锚点的逻辑在哪里、有哪些可以优化的空间、哪些场景下可以和按结果付费结合起来使用。假常识4「只要技术做得足够好按结果付费的问题就能迎刃而解」很多AH工程的技术负责人——包括一些开源AH框架的核心贡献者——都认为「只要技术做得足够好比如幻觉率降到1%以下、任务完成率升到99%以上、成本控制在传统规则引擎的1倍以内按结果付费的问题就能迎刃而解」因为「如果技术做得足够好客户就会信任我们就愿意和我们签订按结果付费的合同就不会有‘试错成本焦虑’和‘结果不可预期的焦虑’」。但实际上按结果付费的问题不仅是一个「技术问题」更是一个「商业问题」、「法律问题」、「风险管控问题」、「信任建立问题」、「结果量化问题」——哪怕你的技术做得完美无缺比如幻觉率降到0%、任务完成率升到100%、成本控制在0元以内这些非技术问题也可能让按结果付费的合同无法签订、无法执行、无法结算——我们后面也会在「深度层」和「多维透视层」详细拆解这些非技术问题的本质在哪里、怎么解决这些非技术问题。假常识5「开源AH框架的商业化只能靠‘卖技术支持’、‘卖企业版’、‘卖云托管服务’」很多开源AH框架的创始人——包括LangChain的创始人Harrison Chase、AutoGen的创始人Chi Wang——都认为「开源AH框架的商业化只能靠‘卖技术支持’、‘卖企业版在开源版的基础上增加一些企业级的功能比如权限管理、监控告警、SLA保障、合规审计、多租户支持’、‘卖云托管服务帮客户在AWS/GCP/Azure/阿里云/腾讯云/华为云上部署、运维、优化AH集群’」因为「开源项目的核心价值是‘代码自由’不能靠‘直接卖代码’赚钱只能靠‘卖围绕代码的服务’赚钱」。但实际上开源AH框架的商业化完全可以和「按Token计费的优化服务」、「按结果付费的风险共担服务」结合起来——比如LangChain可以推出「LangChain Cost Optimizer帮客户优化AH工程的Token调用承诺将Token调用量降低30%以上超出部分按节省的Token费用的20%收费」、「LangChain Result Guarantee帮客户设计、部署、运维、优化特定场景的AH集群承诺达到特定的KPI超出KPI的部分按客户创造的额外价值的10%收费未达到KPI的部分LangChain赔偿客户一定比例的损失」——我们后面也会在「实践转化层」和「整合提升层」详细拆解这些商业化模式的可行性在哪里、怎么落地这些商业化模式。0.3 为什么这个困局对「你」来说很重要不管你是AH工程的从业者技术负责人、开发者、PM、运营负责人、销售负责人、垂直行业的数字化负责人CTO、CIO、CDO、数字化转型项目经理、SAAS公司的创始人或合伙人、AI领域的投资人、开源AH框架的核心贡献者或创始人这个困局对你来说都非常重要——因为它直接关系到你的收入如果你是AH工程的从业者你的工资、奖金、期权可能直接和「AH工程的商业化收入」挂钩如果你是SAAS公司的创始人或合伙人你的公司的估值、融资、甚至生存可能直接和「AH工程的商业化收入」挂钩如果你是开源AH框架的核心贡献者或创始人你的项目的可持续发展、甚至你的个人收入可能直接和「AH工程的商业化收入」挂钩你的成本如果你是垂直行业的数字化负责人你的公司的「AI采购预算」、「数字化转型预算」可能直接和「AH工程的计费模式」挂钩如果你是SAAS公司的创始人或合伙人你的公司的「运营成本」、「毛利率」可能直接和「AH工程的计费模式」挂钩你的客户信任如果你是AH工程的从业者、SAAS公司的创始人或合伙人、开源AH框架的核心贡献者或创始人你的客户对你的信任可能直接和「AH工程的计费模式的透明度、公平性、可预期性」挂钩你的风险管控如果你是垂直行业的数字化负责人、SAAS公司的创始人或合伙人、AI领域的投资人你的公司的「合规风险」、「财务风险」、「声誉风险」可能直接和「AH工程的计费模式的风险共担机制」挂钩你的职业发展如果你是AH工程的从业者、垂直行业的数字化负责人你的职业发展可能直接和「你对AH工程商业化困局的理解、你解决这个困局的能力」挂钩。简单来说这个困局不是「别人的问题」而是「你的问题」——如果你今天不花时间去理解它、去思考它、去解决它明天你可能就会面临「凌晨四点的崩溃」。0.4 这篇技术博客的学习路径概览为了帮你「系统、深入、全面」地理解这个困局、找到解决这个困局的「最优解或者说‘次优但可接受的解’」我们按照「知识金字塔构建者的多维教学系统」设计了以下学习路径概念地图层我们会先帮你建立「AH工程商业化困局」的整体认知框架——包括核心概念、关键术语、概念间的层次与关系、学科定位与边界、思维导图或知识图谱基础理解层我们会用「生活化比喻与类比」、「直观示例与演示」、「关键术语的简明定义」帮你建立「按Token计费」和「按结果付费」的直观认识同时澄清一些常见的误解层层深入层我们会从「第一层基本原理与运作机制」、「第二层细节、例外与特殊情况」、「第三层底层逻辑与理论基础」、「第四层高级应用与拓展思考」四个维度逐步增加复杂度帮你深入理解这个困局的本质多维透视层我们会从「历史视角发展脉络与演变」、「实践视角应用场景与案例」、「批判视角局限性与争议」、「未来视角发展趋势与可能性」四个维度帮你多角度理解这个困局实践转化层我们会从「应用原则与方法论」、「实际操作步骤与技巧」、「常见问题与解决方案」、「案例分析与实战演练」四个维度帮你将知识转化为实际能力整合提升层我们会帮你「回顾与强化核心观点」、「重构与完善知识体系」、「思考问题与拓展任务」、「找到学习资源与进阶路径」。在整个学习过程中我们会用到「多元思维模型」工程思维、设计思维、系统思维、批判思维、创造思维、科学思维、哲学思维、「可视化辅助」概念图谱、流程图解、对比表格、层次结构、视觉隐喻、「数学模型」latex公式、「算法流程图」mermaid流程图、「算法源代码」python源代码、「实际场景应用」、「项目介绍」、「环境安装」、「系统功能设计」、「系统架构设计」、「系统接口设计」、「系统核心实现源代码」、「最佳实践tips」、「行业发展与未来趋势表格」等工具帮你「深入浅出、层层递进、形象生动」地理解这个困局。概念地图建立「AH工程商业化困局」的整体认知框架核心概念核心矛盾变量、利益相关者Stakeholder、约束条件、量化指标体系、风险共担机制、路径依赖机制、AI经济新契约1.1 核心概念与关键术语的简明定义在正式开始建立「整体认知框架」之前我们必须先把「核心概念与关键术语」的「定义边界」划清楚——因为如果「定义边界」划不清楚后面的讨论就会变成「鸡同鸭讲」1.1.1 AH工程领域的核心概念与关键术语术语名称英文名称简明定义定义边界人工智能代理AI Agent能够「感知环境Perceive Environment、做出决策Make Decisions、采取行动Take Actions、实现目标Achieve Goals、从经验中学习Learn from Experience」的智能系统——这个定义来自于Russell和Norvig的《人工智能一种现代的方法》Artificial Intelligence: A Modern Approach是AI领域公认的「AI Agent的标准定义」1. 必须是「智能系统」而不是「传统规则引擎」传统规则引擎只能「按照预设的规则感知环境、做出决策、采取行动」不能「从经验中学习」、不能「处理预设规则之外的情况」2. 必须具备「感知、决策、行动、目标、学习」五个核心要素缺少其中任何一个要素都不能称为「完整的AI Agent」——比如一个只能「感知环境、采取行动」的智能传感器不是AI Agent一个只能「做出决策、实现目标」的决策支持系统不是AI Agent一个只能「从经验中学习」的机器学习模型不是AI Agent3. 这里的「环境」可以是「物理环境」比如机器人的工作车间、「数字环境」比如互联网、企业内部的办公系统、SAAS平台、「混合环境」比如智能家居系统的物理房间数字APP4. 这里的「行动」可以是「物理行动」比如机器人的移动、抓取、操作、「数字行动」比如搜索API调用、数据库API调用、代码执行、文档处理、邮件发送、消息推送、「混合行动」比如智能家居系统的数字APP控制物理设备的开关5. 这里的「目标」可以是「单一目标」比如帮用户订一张明天从北京到上海的最便宜的机票、「多目标」比如帮用户订一张明天从北京到上海的、时间合适的、价格便宜的、有靠窗座位的机票、「动态目标」比如帮用户在旅游过程中根据天气、交通、用户的兴趣动态调整旅游路线6. 这里的「学习」可以是「监督学习」比如用历史对话数据微调轻量级小模型、「强化学习」比如让Agent在虚拟环境中通过试错学习最优任务路径、「无监督学习」比如让Agent从企业内部的知识库中自动挖掘概念间的关系、「半监督学习」比如用少量的标注数据和大量的未标注数据微调轻量级小模型、「迁移学习」比如把一个在零售场景下训练好的Agent迁移到金融场景下使用大语言模型驱动的人工智能代理LLM-powered AI Agent以「大语言模型LLM」为「核心决策大脑」的AI Agent——这是今天AH工程领域最热门、最常用的AI Agent类型1. 必须以「大语言模型」为「核心决策大脑」——这里的「大语言模型」可以是「通用大语言模型」比如GPT-4 Turbo、GPT-4o、Claude 3 Opus、Claude 3.5 Sonnet、Gemini 1.5 Pro、智谱GLM-4、通义千问4、文心一言4.0、讯飞星火4.0、「垂直领域微调大语言模型」比如金融领域微调的GPT-4 Turbo、医疗领域微调的智谱GLM-4、教育领域微调的通义千问4、「轻量级微调大语言模型」比如Llama 3 8B/70B微调、Qwen 2 7B/72B微调、GLM-4 9B/65B微调2. 除了「核心决策大脑LLM」之外还可以具备「其他核心要素」——比如「感知模块感知环境的信息比如用户的文本输入、语音输入、图像输入、视频输入企业内部的数据库更新、外部的API数据更新」、「行动模块采取行动比如工具链调用、代码执行、文档处理」、「记忆模块存储信息比如短期记忆的上下文窗口、长期记忆的向量数据库、元记忆的Agent执行历史和参数配置」、「目标模块设定和调整目标比如用户的明确目标、Agent自己推理出来的隐含目标、动态调整的目标」、「学习模块从经验中学习比如微调轻量级小模型、优化向量语义匹配的算法、调整工具链的调用优先级、通过强化学习学习最优任务路径」3. 这里的「驱动」的意思是「LLM负责Agent的所有核心决策」——比如「是否需要调用工具链调用哪个工具链怎么调用工具链调用完工具链之后怎么处理返回的结果是否需要继续调用工具链是否需要向用户提问是否需要生成最终的回答或决策」——这些决策都由LLM负责而不是由传统规则引擎负责AI Agent Harness EngineeringAI Agent Harness EngineeringAH工程一套「针对AI Agent的、全生命周期的、可监控可迭代的管理系统」——它的核心目标是「让Agent能安全、可控、低成本、可预期地执行任务、创造价值」1. 必须是「针对AI Agent的」——而不是针对「传统软件系统」的2. 必须是「全生命周期的」——覆盖AI Agent的「需求分析阶段、设计阶段、开发阶段、测试阶段、部署阶段、运维阶段、优化阶段、下线阶段」3. 必须是「可监控的」——能够实时监控Agent的「每一步决策、每一次工具调用、每一条生成的内容、每一次任务完成的质量和时间、每一次Token调用的数量和成本」4. 必须是「可迭代的」——能够根据「Agent的执行日志、用户的反馈、业务的变化、合规的要求」快速迭代「约束幻觉的规则、约束成本的规则、约束行为边界的规则、约束任务路径的规则、监控告警的规则」甚至能够「微调轻量级小模型、优化向量语义匹配的算法、调整工具链的调用优先级、通过强化学习学习最优任务路径」5. 核心目标是「安全、可控、低成本、可预期」——这四个目标缺一不可缺少其中任何一个目标都不能称为「完整的AH工程」工具链ToolchainAI Agent可以调用的「一组工具」——这些工具可以帮助Agent「感知环境的更多信息」、「采取更复杂的行动」、「实现更复杂的目标」1. 可以是「单一工具」比如维基百科搜索API、企业内部的CRM数据库API、「组合工具」比如先用维基百科搜索API获取信息再用Python代码执行API处理信息最后用邮件发送API把处理后的信息发送给用户2. 可以是「第三方提供的API工具」比如OpenAI的DALL-E 3图像生成API、谷歌的Google Search API、AWS的Lambda代码执行API、「企业内部开发的API工具」比如企业内部的CRM数据库API、ERP数据库API、OA办公系统API、「开源工具」比如LangChain的内置工具、AutoGPT的内置工具3. 可以是「只读工具」比如维基百科搜索API、企业内部的CRM数据库查询API、「读写工具」比如企业内部的CRM数据库更新API、邮件发送API、代码执行API——读写工具的风险比只读工具高很多必须严格约束4. 可以是「同步工具」比如调用后立即返回结果的工具、「异步工具」比如调用后需要等待一段时间才能返回结果的工具——异步工具的处理逻辑比同步工具复杂很多记忆模块Memory ModuleAI Agent用来「存储信息」的模块——它可以帮助Agent「记住之前的对话、之前的任务执行历史、之前调用过的工具链、之前学习到的知识」1. 可以分为「短期记忆Short-term Memory」、「长期记忆Long-term Memory」、「元记忆Meta-memory」三个层次——这是仿照人类的记忆结构设计的2. 「短期记忆」通常指「LLM的上下文窗口Context Window」——它的存储容量有限比如GPT-4 Turbo的上下文窗口是128K TokenClaude 3.5 Sonnet的上下文窗口是200K TokenGemini 1.5 Pro的上下文窗口是1M Token存储的信息会随着对话的结束或任务的完成而丢失3. 「长期记忆」通常指「向量数据库Vector Database」——它的存储容量几乎无限存储的信息不会随着对话的结束或任务的完成而丢失它可以通过「向量语义匹配」的方式快速检索到和当前对话或当前任务相关的信息4. 「元记忆」通常指「Agent的执行历史数据库、参数配置数据库、用户画像数据库」——它可以帮助Agent「记住自己之前的执行情况、参数配置、用户的偏好和习惯」从而做出更符合用户需求的决策5. 可以是「单一存储介质」比如只用向量数据库作为长期记忆、「组合存储介质」比如用向量数据库作为结构化信息的长期记忆用图数据库作为非结构化信息的长期记忆用关系型数据库作为元记忆约束模块Constraint ModuleAH工程用来「约束Agent的行为」的模块——它可以帮助Agent「避免幻觉、避免超权调用、避免违规内容、避免漫无目的地调用工具链、避免浪费Token」1. 可以分为「静态约束模块」、「动态约束模块」两个层次2. 「静态约束模块」通常指「预设的规则」——比如「只能调用企业授权范围内的工具链」、「只能访问企业授权范围内的知识库和数据接口」、「生成的内容必须符合企业价值观、合规要求、业务规范」、「每轮对话允许调用的工具链数量不能超过N个」、「每轮对话允许调用的高成本大模型API的次数不能超过M次」3. 「动态约束模块」通常指「根据Agent的执行日志、用户的反馈、业务的变化、合规的要求动态调整的规则」——比如「如果Agent在过去的10次对话中出现了3次幻觉就增加约束幻觉的规则的严格程度」、「如果Agent在过去的10次任务执行中Token调用量超预期50%就增加约束成本的规则的严格程度」4. 可以是「基于规则的约束模块」、「基于模型的约束模块」两个类型——「基于规则的约束模块」执行速度快、可解释性强但灵活性差「基于模型的约束模块」灵活性强但执行速度慢、可解释性差、成本高监控告警模块Monitoring and Alerting ModuleAH工程用来「监控Agent的执行过程、并在出现异常情况时发出告警」的模块——它可以帮助企业「立即发现异常情况、立即停止Agent的执行、立即转人工干预、立即回溯错误原因」1. 可以监控的「异常情况」包括「幻觉、超权调用、违规内容、任务失败、任务超时、成本异常、Token调用异常、用户投诉」2. 可以发出的「告警方式」包括「邮件告警、短信告警、企业微信/钉钉/飞书告警、电话告警、界面弹窗告警」3. 可以设置的「告警级别」包括「低级别比如用户反馈‘Agent的回答不够清晰’、中级别比如Agent出现了1次幻觉、Token调用量超预期20%、高级别比如Agent出现了3次以上的幻觉、超权调用了读写工具、生成了违规内容、成本异常超预期100%、收到了用户的工商投诉举报的苗头线索」4. 可以设置的「告警响应机制」包括「低级别告警记录日志、不需要立即处理、第二天统一分析中级别告警记录日志、立即通知AH工程的运营负责人、运营负责人在30分钟内处理高级别告警记录日志、立即停止Agent的执行、立即转人工干预、立即通知AH工程的技术负责人、销售负责人、客服总监、甚至创始人、技术负责人在15分钟内回溯错误原因」迭代优化模块Iterative Optimization ModuleAH工程用来「根据Agent的执行日志、用户的反馈、业务的变化、合规的要求快速迭代优化Agent」的模块——它可以帮助Agent「执行质量越来越高、执行成本越来越低、执行效率越来越快」1. 可以迭代优化的「内容」包括「约束模块的规则、监控告警模块的规则、记忆模块的向量语义匹配算法、工具链的调用优先级、轻量级小模型的参数、Agent的任务路径规划算法」2. 可以采用的「迭代优化方法」包括「人工迭代优化由AH工程的技术负责人、PM、运营负责人根据执行日志和用户的反馈手动调整、半自动迭代优化由AI辅助工具生成调整建议由人工审核后执行、全自动迭代优化由AI辅助工具自动生成调整建议、自动执行调整、自动验证调整效果」3. 可以设置的「迭代优化周期」包括「实时迭代优化比如根据每一次对话的用户反馈实时调整Agent的参数、每日迭代优化比如根据每天的执行日志和用户的反馈每天调整一次、每周迭代优化比如根据每周的执行日志和用户的反馈每周调整一次、每月迭代优化比如根据每月的KPI完成情况每月调整一次」1.1.2 商业化领域的核心概念与关键术语术语名称英文名称简明定义定义边界按使用量计费Usage-based PricingUBP一种「根据用户的实际使用量来收费」的计费模式——这是今天传统云服务、AI大模型API服务最常用的计费模式1. 这里的「使用量」可以是「CPU时长」比如AWS EC2按CPU核数×使用时长收费、「存储空间」比如AWS S3按存储的文件大小×存储时长收费、「流量」比如AWS CloudFront按流出的流量收费、「API调用次数」比如OpenAI早期的GPT-3按API调用次数收费、「Token调用量」比如今天的OpenAI GPT-4 Turbo、Claude 3.5 Sonnet、智谱GLM-4按Token调用量收费、「查询次数」比如向量数据库按向量查询次数收费2. 可以分为「阶梯式按使用量计费」比如使用量在0-100万之间按单价X收费100万-1000万之间按单价Y收费1000万以上按单价Z收费XYZ、「线性按使用量计费」比如不管使用量多少都按统一的单价收费、「套餐式按使用量计费」比如用户先支付一笔固定的费用获得一定的使用量超出部分按阶梯式或线性单价收费3. 核心特点是「透明度高、可预测性强如果用户能控制自己的使用量、成本和使用量成正比」——对于提供服务的厂商来说这种计费模式的「收入可预测性强如果用户的使用量稳定、现金流好」对于使用服务的用户来说这种计费模式的「试错成本低可以先少量使用测试效果再决定是否大量使用、成本和价值成正比如果使用量和创造的价值成正比」按Token计费Token-based Pricing按使用量计费的一种特殊类型——「根据用户的实际Token调用量来收费」——这是今天AI大模型API服务、AH工程服务最常用的计费模式之一1. 这里的「Token」是「大语言模型处理文本的基本单位」——不同的大语言模型对「Token」的定义略有不同但一般来说「1个Token≈0.75个英文单词≈1个中文汉字或者说1个中文汉字≈1.3个Token」——比如OpenAI的Tokenizer可以把文本转换成Token我们可以用OpenAI的Tokenizer Demohttps://platform.openai.com/tokenizer来测试文本的Token数量2. 这里的「Token调用量」包括「输入TokenPrompt Token的数量」和「输出TokenCompletion Token的数量」——一般来说输出Token的单价比输入Token的单价高2-5倍比如OpenAI GPT-4 Turbo的输入Token单价是0.01美元/1K Token输出Token单价是0.03美元/1K Token智谱GLM-4的输入Token单价是0.1元人民币/1K Token输出Token单价是0.3元人民币/1K Token3. 可以分为「纯按Token计费」比如不管任务完成的质量如何都按实际Token调用量收费、「TokenSLA计费」比如在纯按Token计费的基础上增加SLA保障——比如任务完成率≥95%、响应时间≤1秒、如果未达到SLA就赔偿用户一定比例的Token费用4. 核心特点和按使用量计费类似——「透明度高、可预测性强如果用户能控制自己的Token调用量、成本和使用量成正比」——但有一个特殊的问题「Token调用量和创造的价值不一定成正比」——比如我们前面举的例子一个Agent用1000个Token完成了一个能为客户创造100万元价值的任务另一个Agent用10万个Token完成了一个能为客户创造1000元价值的任务按纯按Token计费的话前者的收入只有后者的1%但前者创造的价值是后者的1000倍这显然是不公平的按结果付费Outcome-based PricingOBP一种「根据用户的实际结果或者说实际创造的价值来收费」的计费模式——这是今天很多垂直行业的咨询服务、广告服务、SAAS服务比如按销售额提成的电商SAAS服务常用的计费模式之一也是很多人认为的「AH工程商业化的唯一正确方向」1. 这里的「结果」必须是「可量化、可验证、可归因」的——这是按结果付费的前提条件如果结果不能量化、不能验证、不能归因按结果付费的合同就无法签订、无法执行、无法结算2. 这里的「可量化」的意思是「结果必须能用数字来表示」——比如「首月转人工率降30%」、「NPS升15%」、「客单价提升20%」、「销售额提升10%」、「成本降低25%」3. 这里的「可验证」的意思是「结果必须能用客观的数据来验证」——比如「转人工率」可以用客服系统的日志来验证「NPS」可以用用户调研的数据来验证「客单价」可以用电商系统的订单数据来验证「销售额」可以用财务系统的数据来验证4. 这里的「可归因」的意思是「结果必须能明确归因于AH工程的使用」——这是按结果付费最难的地方因为「结果往往是由多个因素共同作用的」——比如「电商销售额的提升」可能是由「AH工程的使用」、「促销活动的开展」、「市场环境的变化」、「竞争对手的变化」、「产品质量的提升」、「物流效率的提升」等多个因素共同作用的很难明确归因于AH工程的使用5. 可以分为「纯按结果付费」比如没有固定的费用完全按实际结果收费——比如销售额提升10%就收提升部分的10%作为费用、「固定费用按结果提成」比如先支付一笔固定的费用覆盖AH工程的设计、开发、部署的成本再按实际结果的提成比例收取额外的费用、「风险共担收益共享」比如如果未达到预设的KPIAH工程服务商就赔偿用户一定比例的损失如果超出预设的KPIAH工程服务商就收取超出部分的一定比例的收益——这是一种「双赢」的计费模式但风险也很大6. 核心特点是「用户为价值付费而不是为手段付费」——对于使用服务的用户来说这种计费模式的「试错成本低甚至没有试错成本——如果未达到预设的KPI用户不需要支付费用甚至可以获得赔偿、价值显性化」对于提供服务的厂商来说这种计费模式的「收入上限高如果超出预设的KPI可以获得很高的收益、客户粘性强因为用户的价值和厂商的收入绑定在一起」——但也有一个特殊的问题「风险很大、结果很难量化、很难验证、很难归因、收入可预测性差、现金流差」利益相关者Stakeholder能够「影响AH工程商业化困局的解决」或者「被AH工程商业化困局的解决影响」的个人或组织——在这个困局中主要的利益相关者包括「AH工程服务商」、「AI大模型厂商」、「云服务商」、「垂直行业的客户用户」、「开源AH框架的核心贡献者或创始人」、「AI领域的投资人」、「监管机构」1. 每个利益相关者都有自己的「利益诉求」和「约束条件」——我们后面会在「深度层」详细分析每个利益相关者的利益诉求和约束条件2. 这个困局的本质就是「各个利益相关者的利益诉求之间的冲突」——比如「AH工程服务商希望收入高、风险低、现金流好」「垂直行业的客户希望成本低、价值高、风险低、可预期性强」「AI大模型厂商希望收入高、收入可预测性强、现金流好」这三个利益相关者的利益诉求之间存在明显的冲突3. 解决这个困局的关键就是「找到一个能够平衡各个利益相关者的利益诉求的方案」约束条件Constraint限制「AH工程商业化困局的解决」的因素——在这个困局中主要的约束条件包括「技术约束」、「商业约束」、「法律约束」、「风险管控约束」、「信任建立约束」、「市场成熟度约束」1. 每个约束条件都有自己的「边界」和「可调整的空间」——我们后面会在「深度层」详细分析每个约束条件的边界和可调整的空间2. 解决这个困局的关键就是「在现有的约束条件下找到一个最优解或者说次优但可接受的解」同时「努力突破一些可以突破的约束条件」量化指标体系Quantitative Indicator System一组「用来量化AH工程的价值、成本、风险、执行质量」的指标——它是按结果付费的前提条件也是按Token计费的优化依据1. 可以分为「价值指标」、「成本指标」、「风险指标」、「执行质量指标」四个维度2. 「价值指标」可以是「转人工率降幅」、「NPS升幅」、「客单价提升」、「销售额提升」、「成本降低」、「工作效率提升」、「用户满意度提升」3. 「成本指标」可以是「Token调用成本」、「云服务成本」、「AH工程的设计开发部署运维优化成本」、「人工干预成本」4. 「风险指标」可以是「幻觉率」、「超权调用率」、「违规内容率」、「任务失败率」、「用户投诉率」、「工商投诉举报率」5. 「执行质量指标」可以是「任务完成率」、「任务准确率」、「任务响应时间」、「任务超时率」、「工具调用准确率」6. 每个指标都必须是「可量化、可验证、可归因」的——至少是「相对可量化、相对可验证、相对可归因」的风险共担机制Risk-sharing Mechanism一种「用来分配AH工程商业化过程中的风险的机制」——它是按结果付费的核心保障也是平衡各个利益相关者的利益诉求的关键1. 这里的「风险」包括「技术风险比如幻觉率过高、任务失败率过高」、「商业风险比如结果不能量化、不能验证、不能归因、收入可预测性差、现金流差」、「法律风险比如超权调用导致的数据泄露、违规内容导致的法律纠纷」、「声誉风险比如用户投诉、工商投诉举报导致的声誉损失」2. 可以分为「按比例分配风险」比如AH工程服务商承担30%的风险垂直行业的客户承担70%的风险、「按KPI完成情况分配风险」比如如果未达到预设的KPI的80%AH工程服务商承担100%的风险如果达到预设的KPI的80%-100%AH工程服务商承担50%的风险垂直行业的客户承担50%的风险如果达到预设的KPI的100%以上垂直行业的客户承担100%的风险AH工程服务商获得额外的收益、「通过保险转移风险」比如AH工程服务商购买「AH工程责任险」把一部分风险转移给保险公司3. 一个好的风险共担机制应该是「双赢」的——既不能让AH工程服务商承担过多的风险否则AH工程服务商可能会因为风险过大而不愿意签订按结果付费的合同也不能让垂直行业的客户承担过多的风险否则垂直行业的客户可能会因为风险过大而不愿意使用AH工程服务路径依赖机制Path Dependence Mechanism一种「人类社会或技术系统在发展过程中一旦选择了某条路径就会沿着这条路径一直走下去即使这条路径不是最优的也很难改变」的机制——这个概念是由美国经济学家道格拉斯·诺斯Douglass North提出的他也因此获得了1993年的诺贝尔经济学奖1. 在这个困局中路径依赖机制主要体现在「按Token计费的延续性」上——因为「今天的传统云服务、AI大模型API服务都是按使用量包括按Token计费的AH工程服务商已经习惯了这种计费模式垂直行业的客户也已经习惯了这种计费模式AI大模型厂商和云服务商也已经建立了完善的按使用量计费的基础设施和运营体系所以即使按Token计费有很多缺陷也很难在短时间内改变」2. 路径依赖机制的「打破」需要「强大的外部力量」或者「内部的技术突破、商业突破、法律突破」——比如「如果有一个AH工程服务商推出了一种非常成功的按结果付费的商业模式并且获得了很高的收入和估值那么其他AH工程服务商就会纷纷效仿路径依赖机制就可能会被打破」或者「如果有一个技术突破让结果的量化、验证、归因变得非常容易那么按结果付费的商业模式就可能会成为主流路径依赖机制就可能会被打破」AI经济新契约New AI Economy Contract一种「针对AI技术包括AH工程的、新的商业契约」——它的核心思想是「用户为价值付费而不是为手段付费风险共担收益