1. 从功能订阅到任务交付SaaS的计价锚点正在漂移过去十几年SaaS这门生意的底层逻辑其实非常朴素把一套标准化的软件功能放在云上按人头、按月或按年收订阅费。客户买的是工具的使用权厂商卖的是功能的持续可用。这个模型之所以成立是因为软件的价值边界清晰——它帮你把某件事做得更快、更规范但最终动手的还是人。Agent的介入把这个边界彻底打穿了。当软件不再只是等你来操作而是能自己理解目标、拆解任务、调用工具、执行动作、校验结果时客户真正付费的对象就变了。他不再关心你有多少个功能菜单他关心的是这件事你到底替我办成了没有。计价锚点从席位漂移到任务从功能可用性漂移到结果达成率。这不是一次简单的产品升级而是商业模式的重新定价。我先把结论摆在这里SaaS的Agent化本质是把软件从工具供应商变成任务承包方价值计算的分母从人变成了任务分子从功能数量变成了任务完成质量。后面所有的技术选型、架构设计、定价策略都是围绕这个公式在转。1.1 为什么按席位收费在Agent场景下会失灵按席位收费的前提是一个人对应一份工作量。但Agent的典型特征是一个Agent可以顶掉原本需要多个席位协作才能完成的流程。比如一份合同审查过去需要法务助理初筛、法务专员复核、主管签字三个环节对应三个席位。现在一个配置得当的审查Agent可以在几分钟内完成初筛和风险标注人只需要做最终确认。这时候你如果还按三个席位收费客户会立刻算一笔账我明明只留了一个人凭什么付三份钱但如果你只收一个席位的钱你的收入就随着Agent效率的提升而不断缩水——效率越高收入越低这是个死亡螺旋。所以Agent时代的定价必须换锚。常见的几种思路我实测下来各有适用场景计价模式计价单位适用场景主要风险按任务量每次任务执行任务边界清晰、可计数客户可能拆分任务规避计费按结果成功交付次数结果可验证、可量化失败任务的责任界定复杂按节省节省的人力成本分成效果可归因归因模型难做易扯皮混合制基础订阅任务超额大多数企业级场景需要精细的用量监控我个人更倾向混合制保留一个较低的基础订阅覆盖平台的持续维护成本然后按任务执行量或结果达成量做阶梯计价。这样既保证了厂商的现金流底线又让客户觉得用多少付多少是公平的。1.2 价值重算的三个核心变量要把这笔账算清楚得盯住三个变量。第一个是任务替代率也就是这个Agent到底能替代多少原本由人完成的工作。这个数字不能拍脑袋得从真实的工作流里拆出来。我的做法是先把一个岗位的日常工作拆成任务清单逐条标注可完全替代可辅助不可替代然后算出加权替代率。低于30%的场景Agent化投入产出比通常不划算。第二个是任务成功率。Agent不是万能的它会有幻觉、会调错工具、会在边界情况下卡住。一个成功率70%的Agent和一个成功率95%的Agent商业价值差着数量级。因为失败的任务往往需要人来兜底兜底成本可能比人从头做还高。所以成功率是定价的硬约束不是营销话术。第三个是单任务成本。这里面包含推理成本、工具调用成本、人工兜底成本。很多人只算了推理的token钱忽略了兜底的人力成本结果算出来的毛利是虚的。我见过一个团队Agent单次任务推理成本两毛钱看起来很美好但加上15%的失败兜底实际单任务成本接近三块。把这三个变量乘起来才是Agent真正创造的价值。这个价值除以你的定价就是客户感知的ROI。ROI低于2倍企业客户基本不会买单。2. Agent Harness被大多数人忽略的价值放大器热词里反复出现harness这个词很多人第一反应是这不就是个跑Agent的壳子吗。如果你也这么想那你可能错过了Agent工程里最值钱的一块。Harness不是壳子它是Agent的操作系统层。它负责的事情包括任务的接收与解析、上下文的组装与裁剪、工具的注册与调度、执行过程的监控与中断、失败的重试与回滚、结果的校验与交付。换句话说模型负责想Harness负责让想法安全、可控、可复现地落地。2.1 Harness和Agent到底差在哪这个问题被问得最多我用一个类比说清楚。Agent是司机Harness是整辆车加上交通规则加上行车记录仪。司机再聪明如果没有刹车、没有仪表盘、没有安全带、没有路线约束你敢让他上高速吗Agent的智能程度决定了它能开多快Harness的工程成熟度决定了它敢不敢让你上路。具体到技术层面两者的职责边界是这样的Agent层负责意图理解、任务规划、工具选择、结果生成。这一层高度依赖模型能力是智能的来源。Harness层负责生命周期管理、状态持久化、并发控制、错误处理、可观测性、安全护栏。这一层高度依赖工程能力是可靠的来源。我踩过的一个坑很能说明问题。早期我写了一个Agent做数据清洗逻辑跑通了demo很漂亮。但一上生产就崩并发一高多个任务共享上下文互相污染任务跑到一半服务重启状态全丢某个工具调用超时整个流程卡死没有超时熔断。这些问题没有一个是模型能解决的全是Harness的活。后来我把Harness重写了一遍加了任务隔离、状态快照、超时熔断、幂等重试同样的Agent逻辑成功率从60%出头拉到了95%以上。模型没换价值翻了一倍多。这就是Harness的价值放大器效应。2.2 一个能扛住生产的Harness该有哪些模块我把自己的Harness拆成了六个核心模块每个模块都对应一类生产事故。任务编排器负责接收任务、解析成可执行的步骤图、按依赖关系调度。这里的关键是支持中断和恢复任务不能是一锤子买卖得能暂停、能续跑。上下文管理器负责组装模型需要的上下文包括系统提示、历史对话、工具描述、检索结果。难点在于裁剪——上下文窗口是有限的什么该留什么该丢直接决定Agent的判断质量。我的经验是给不同类型的上下文打优先级标签超限时按优先级从低到高丢弃。工具网关所有外部工具的调用都走这一层统一做鉴权、限流、超时、重试、日志。这样Agent本身不需要关心工具怎么调只需要声明我要调什么。状态存储任务的每一步状态都持久化支持快照和回放。这不仅是容灾需要更是调试需要——Agent出错时你得能回放到出错那一步看看到底发生了什么。可观测层记录每个任务的完整轨迹包括模型输入输出、工具调用参数和结果、耗时、token消耗。没有这层你根本不知道钱花在哪、错出在哪。安全护栏输入过滤、输出校验、敏感操作二次确认、权限边界控制。Agent能自己动手就意味着它也能自己闯祸护栏是底线。2.3 为什么说Harness工程是SaaS公司的护城河模型能力是公共资源今天你用的模型明天别人也能用甚至可能更便宜。但Harness是私有的它沉淀的是你对特定业务场景的理解——哪些任务容易失败、失败后怎么补救、哪些工具组合最稳、上下文怎么裁剪最有效。这些东西模型厂商给不了你只能自己趟出来。所以我的判断是SaaS公司在Agent时代的核心竞争力不在模型层而在Harness层。谁把Harness工程做得更扎实谁就能在同样的模型能力下做出更高的任务成功率、更低的单任务成本从而在定价上有更大的腾挪空间。3. 并发、成本与安全Agent落地绕不开的三道坎Demo跑通和产品上线之间隔着三道坎。这三道坎我在不同项目里反复遇到每一道都能让一个看起来美好的Agent项目搁浅。3.1 并发不是加机器就能解决的Agent的并发和传统Web服务的并发完全不是一回事。传统请求是无状态的、短时的、可水平扩展的。Agent任务是长时的、有状态的、步骤间有依赖的。一个Agent任务可能跑几分钟甚至几十分钟中间要调十几次模型、几十次工具。如果你用传统的一个请求一个线程模型并发一上来线程池瞬间打满。如果你用异步那状态管理、超时控制、错误传播的复杂度会指数级上升。我实测下来比较稳的方案是任务队列加工作池的模式任务进来先入队返回一个任务ID前端轮询或走推送拿结果。工作池里的worker从队列取任务执行worker数量根据下游模型和工具的承载能力来定。每个任务的状态独立存储worker崩了任务能重新入队。对下游调用做统一的限流和熔断防止一个慢工具拖垮整个池子。这里有个容易忽略的点并发控制要分层做。任务级并发、模型调用级并发、工具调用级并发三层的限流阈值要分别设置。我见过只做了任务级限流结果一百个任务同时打同一个外部API直接把对方打挂的情况。还有一个坑是上下文的内存占用。Agent的上下文动辄几万token一百个并发任务同时持有上下文内存消耗非常可观。我的做法是上下文不常驻内存用完即序列化落盘需要时再加载。牺牲一点延迟换内存安全。3.2 单任务成本必须算到骨头里Agent的成本结构比传统SaaS复杂得多因为它同时消耗推理资源和工具资源。我一般按这个公式拆单任务成本 模型推理成本 工具调用成本 存储与计算成本 失败兜底成本模型推理成本最好算输入输出token乘以单价。但要注意Agent任务往往是多轮推理一轮任务可能调五六次模型成本是单次问答的好几倍。工具调用成本容易被低估。有些外部API是按次收费的Agent如果规划能力差反复调同一个工具成本会失控。我的做法是给每个任务设工具调用次数上限超了就中断并告警。失败兜底成本是最隐蔽的。一个失败的任务要么重试成本翻倍要么转人工人力成本。如果失败率是10%那这10%的成本要摊到所有任务上。所以降低失败率本身就是降本。我做过一个粗略的测算一个中等复杂度的Agent任务如果成功率从80%提到95%单任务综合成本能降30%以上。提升成功率比优化token单价更划算这个结论我验证过好几次。3.3 安全护栏要在设计阶段就焊死Agent能自己调工具、自己执行动作这意味着它的破坏力远大于一个只会聊天的模型。安全护栏不能事后补必须设计阶段就焊死。我的护栏分四层输入层过滤恶意指令、越权请求、注入攻击。特别是当Agent会读取外部内容时要防止外部内容里藏指令劫持Agent行为。决策层对Agent规划出的动作做校验高危动作删除、转账、对外发送必须走二次确认或人工审批。执行层工具调用做权限最小化Agent只能调它被授权的工具且工具本身要有参数校验。输出层对Agent的产出做合规校验防止泄露敏感信息或生成不当内容。这四层里决策层的二次确认机制最关键也最难做。做太严Agent的自动化价值就没了做太松风险兜不住。我的经验是按动作的可逆性来分级可逆动作查询、草稿直接放行不可逆动作删除、发送、支付强制确认。这样既保住了大部分自动化收益又守住了底线。4. 从Agentic Coding到多Agent协作能力边界的真实推演热词里agentic coding、多AI协作、agent框架这些词出现频率很高说明大家都在往这个方向探。我结合自己的实践聊聊这些能力到底能走到哪一步。4.1 Agentic Coding改变了什么没改变什么Agentic Coding简单说就是让Agent自己写代码、自己调试、自己迭代。这个方向确实在快速进步我日常也在用效率提升是实打实的。但它改变的是编码这个环节的效率没有改变定义问题和验收结果这两个环节。Agent能帮你把一个明确的需求实现出来但需求本身是否合理、边界是否清晰、验收标准是什么这些还得人来定。我见过太多团队指望Agent自动搞定一切结果需求本身是模糊的Agent产出的东西看着像那么回事一验收全是坑。所以我的用法是把Agent当成一个执行力极强但需要明确指令的初级工程师。给它清晰的任务描述、明确的输入输出约定、可运行的测试用例它能干得很漂亮。指令模糊它就自由发挥发挥出来的东西你得花更多时间收拾。4.2 多Agent协作的适用边界多Agent协作听起来很美——让一个Agent规划、一个Agent执行、一个Agent审查互相配合。但我在实践中发现多Agent的收益是有条件的。适合多Agent的场景通常满足两个条件任务可清晰分解且子任务之间耦合度低。比如一个内容生产流程选题Agent、写作Agent、审核Agent各管一段交接物是明确的文本这种就适合。不适合的场景是任务高度耦合、需要频繁来回沟通的。这种场景下多Agent之间的通信成本会吃掉协作收益还不如一个能力强的单Agent加一套好的Harness。我踩过的坑是早期迷信多Agent把一个本该单Agent做的任务拆成三个Agent结果三个Agent之间来回传上下文token消耗翻了三倍成功率反而降了。后来合并回单Agent加了更完善的Harness效果立刻好转。多Agent不是银弹它是特定场景下的优化手段不是默认架构。4.3 Agent框架选型的几个务实考量框架选型上我的建议是别被功能最全迷惑要看最贴合你的Harness需求。考量维度关键问题我的倾向状态管理是否原生支持任务持久化和恢复必须有否则生产不可用可观测性是否提供完整的执行轨迹必须有否则无法调优工具集成接入自定义工具的难度越简单越好减少胶水代码并发模型是否支持任务级隔离必须有否则并发会互相污染社区活跃度出问题能否快速找到答案重要但不作为首要标准我个人的经验是框架能覆盖80%的通用需求就够了剩下20%的业务特异性需求靠自己在Harness层扩展。指望一个框架解决所有问题最后往往是被框架的抽象绑住手脚。5. 软件公司该怎么重新算这笔账回到标题那句话——软件公司的价值要重新计算了。怎么算我给一套我自己在用的思路。5.1 先算清楚你的任务资产传统SaaS公司盘点的是功能清单Agent时代要盘点的是任务资产。也就是你的产品到底能替客户完成哪些任务每个任务的替代率、成功率、单任务成本是多少。这个盘点做完你会得到一张任务价值表。表里ROI高的任务就是你应该优先Agent化的方向ROI低甚至为负的先别碰。很多公司一上来就想做全能Agent结果每个任务都做得半吊子成功率上不去成本下不来客户用两次就跑了。聚焦是Agent时代最重要的产品策略。与其做十个成功率60%的任务不如做一个成功率95%的任务。5.2 定价要跟着价值走不是跟着成本走成本加成定价在Agent时代会吃大亏。因为Agent的价值不是线性的——一个成功率95%的Agent客户愿意付的价格可能是成功率70%的Agent的三倍但两者的成本差距可能只有30%。所以定价要锚定客户感知的价值而不是你的成本。客户感知的价值来自这个任务我自己做要花多少人力、多少时间、多少出错成本。你的定价只要显著低于这个数客户就有动力买单。我一般会做一次客户侧的ROI测算把人工完成成本和Agent完成成本摆在一起给客户看。这个对比越清晰成交越顺。5.3 组织能力也要跟着重算最后说一个容易被忽略的点Agent化不只是产品和技术的事组织能力也得跟着变。传统SaaS公司的核心能力是产品设计和工程实现。Agent时代核心能力变成了三样场景理解能力知道哪些任务值得Agent化、Harness工程能力把Agent做得可靠可控、效果运营能力持续监控成功率、成本、客户满意度并迭代。这三样能力里场景理解和效果运营是很多技术型公司欠缺的。我见过技术很强的团队Harness做得漂亮但选错了场景做出来的Agent没人用。也见过场景选得准的团队但Harness太糙成功率上不去客户流失。所以我的建议是Agent化转型要三管齐下别只盯着技术。技术是基础但决定成败的往往是场景选择和持续运营。我在实际推进这类项目时最大的体会是别把Agent当成一个功能来做把它当成一个数字员工来运营。功能上线就完事了员工是要持续培训、考核、优化的。这个心态的转变比任何技术选型都重要。你得像管人一样管你的Agent——给它清晰的职责、明确的考核标准、持续的反馈迭代它才能真正替你创造价值。那些把Agent当功能做的团队最后大多停在demo阶段把它当员工运营的才真正跑出了商业闭环。 
长河君 · 2026/10/28 18:06:57 · 阅读 1.2k SaaS的Agent化：从功能订阅到任务交付的价值重算
1. 从功能订阅到任务交付SaaS的计价锚点正在漂移过去十几年SaaS这门生意的底层逻辑其实非常朴素把一套标准化的软件功能放在云上按人头、按月或按年收订阅费。客户买的是工具的使用权厂商卖的是功能的持续可用。这个模型之所以成立是因为软件的价值边界清晰——它帮你把某件事做得更快、更规范但最终动手的还是人。Agent的介入把这个边界彻底打穿了。当软件不再只是等你来操作而是能自己理解目标、拆解任务、调用工具、执行动作、校验结果时客户真正付费的对象就变了。他不再关心你有多少个功能菜单他关心的是这件事你到底替我办成了没有。计价锚点从席位漂移到任务从功能可用性漂移到结果达成率。这不是一次简单的产品升级而是商业模式的重新定价。我先把结论摆在这里SaaS的Agent化本质是把软件从工具供应商变成任务承包方价值计算的分母从人变成了任务分子从功能数量变成了任务完成质量。后面所有的技术选型、架构设计、定价策略都是围绕这个公式在转。1.1 为什么按席位收费在Agent场景下会失灵按席位收费的前提是一个人对应一份工作量。但Agent的典型特征是一个Agent可以顶掉原本需要多个席位协作才能完成的流程。比如一份合同审查过去需要法务助理初筛、法务专员复核、主管签字三个环节对应三个席位。现在一个配置得当的审查Agent可以在几分钟内完成初筛和风险标注人只需要做最终确认。这时候你如果还按三个席位收费客户会立刻算一笔账我明明只留了一个人凭什么付三份钱但如果你只收一个席位的钱你的收入就随着Agent效率的提升而不断缩水——效率越高收入越低这是个死亡螺旋。所以Agent时代的定价必须换锚。常见的几种思路我实测下来各有适用场景计价模式计价单位适用场景主要风险按任务量每次任务执行任务边界清晰、可计数客户可能拆分任务规避计费按结果成功交付次数结果可验证、可量化失败任务的责任界定复杂按节省节省的人力成本分成效果可归因归因模型难做易扯皮混合制基础订阅任务超额大多数企业级场景需要精细的用量监控我个人更倾向混合制保留一个较低的基础订阅覆盖平台的持续维护成本然后按任务执行量或结果达成量做阶梯计价。这样既保证了厂商的现金流底线又让客户觉得用多少付多少是公平的。1.2 价值重算的三个核心变量要把这笔账算清楚得盯住三个变量。第一个是任务替代率也就是这个Agent到底能替代多少原本由人完成的工作。这个数字不能拍脑袋得从真实的工作流里拆出来。我的做法是先把一个岗位的日常工作拆成任务清单逐条标注可完全替代可辅助不可替代然后算出加权替代率。低于30%的场景Agent化投入产出比通常不划算。第二个是任务成功率。Agent不是万能的它会有幻觉、会调错工具、会在边界情况下卡住。一个成功率70%的Agent和一个成功率95%的Agent商业价值差着数量级。因为失败的任务往往需要人来兜底兜底成本可能比人从头做还高。所以成功率是定价的硬约束不是营销话术。第三个是单任务成本。这里面包含推理成本、工具调用成本、人工兜底成本。很多人只算了推理的token钱忽略了兜底的人力成本结果算出来的毛利是虚的。我见过一个团队Agent单次任务推理成本两毛钱看起来很美好但加上15%的失败兜底实际单任务成本接近三块。把这三个变量乘起来才是Agent真正创造的价值。这个价值除以你的定价就是客户感知的ROI。ROI低于2倍企业客户基本不会买单。2. Agent Harness被大多数人忽略的价值放大器热词里反复出现harness这个词很多人第一反应是这不就是个跑Agent的壳子吗。如果你也这么想那你可能错过了Agent工程里最值钱的一块。Harness不是壳子它是Agent的操作系统层。它负责的事情包括任务的接收与解析、上下文的组装与裁剪、工具的注册与调度、执行过程的监控与中断、失败的重试与回滚、结果的校验与交付。换句话说模型负责想Harness负责让想法安全、可控、可复现地落地。2.1 Harness和Agent到底差在哪这个问题被问得最多我用一个类比说清楚。Agent是司机Harness是整辆车加上交通规则加上行车记录仪。司机再聪明如果没有刹车、没有仪表盘、没有安全带、没有路线约束你敢让他上高速吗Agent的智能程度决定了它能开多快Harness的工程成熟度决定了它敢不敢让你上路。具体到技术层面两者的职责边界是这样的Agent层负责意图理解、任务规划、工具选择、结果生成。这一层高度依赖模型能力是智能的来源。Harness层负责生命周期管理、状态持久化、并发控制、错误处理、可观测性、安全护栏。这一层高度依赖工程能力是可靠的来源。我踩过的一个坑很能说明问题。早期我写了一个Agent做数据清洗逻辑跑通了demo很漂亮。但一上生产就崩并发一高多个任务共享上下文互相污染任务跑到一半服务重启状态全丢某个工具调用超时整个流程卡死没有超时熔断。这些问题没有一个是模型能解决的全是Harness的活。后来我把Harness重写了一遍加了任务隔离、状态快照、超时熔断、幂等重试同样的Agent逻辑成功率从60%出头拉到了95%以上。模型没换价值翻了一倍多。这就是Harness的价值放大器效应。2.2 一个能扛住生产的Harness该有哪些模块我把自己的Harness拆成了六个核心模块每个模块都对应一类生产事故。任务编排器负责接收任务、解析成可执行的步骤图、按依赖关系调度。这里的关键是支持中断和恢复任务不能是一锤子买卖得能暂停、能续跑。上下文管理器负责组装模型需要的上下文包括系统提示、历史对话、工具描述、检索结果。难点在于裁剪——上下文窗口是有限的什么该留什么该丢直接决定Agent的判断质量。我的经验是给不同类型的上下文打优先级标签超限时按优先级从低到高丢弃。工具网关所有外部工具的调用都走这一层统一做鉴权、限流、超时、重试、日志。这样Agent本身不需要关心工具怎么调只需要声明我要调什么。状态存储任务的每一步状态都持久化支持快照和回放。这不仅是容灾需要更是调试需要——Agent出错时你得能回放到出错那一步看看到底发生了什么。可观测层记录每个任务的完整轨迹包括模型输入输出、工具调用参数和结果、耗时、token消耗。没有这层你根本不知道钱花在哪、错出在哪。安全护栏输入过滤、输出校验、敏感操作二次确认、权限边界控制。Agent能自己动手就意味着它也能自己闯祸护栏是底线。2.3 为什么说Harness工程是SaaS公司的护城河模型能力是公共资源今天你用的模型明天别人也能用甚至可能更便宜。但Harness是私有的它沉淀的是你对特定业务场景的理解——哪些任务容易失败、失败后怎么补救、哪些工具组合最稳、上下文怎么裁剪最有效。这些东西模型厂商给不了你只能自己趟出来。所以我的判断是SaaS公司在Agent时代的核心竞争力不在模型层而在Harness层。谁把Harness工程做得更扎实谁就能在同样的模型能力下做出更高的任务成功率、更低的单任务成本从而在定价上有更大的腾挪空间。3. 并发、成本与安全Agent落地绕不开的三道坎Demo跑通和产品上线之间隔着三道坎。这三道坎我在不同项目里反复遇到每一道都能让一个看起来美好的Agent项目搁浅。3.1 并发不是加机器就能解决的Agent的并发和传统Web服务的并发完全不是一回事。传统请求是无状态的、短时的、可水平扩展的。Agent任务是长时的、有状态的、步骤间有依赖的。一个Agent任务可能跑几分钟甚至几十分钟中间要调十几次模型、几十次工具。如果你用传统的一个请求一个线程模型并发一上来线程池瞬间打满。如果你用异步那状态管理、超时控制、错误传播的复杂度会指数级上升。我实测下来比较稳的方案是任务队列加工作池的模式任务进来先入队返回一个任务ID前端轮询或走推送拿结果。工作池里的worker从队列取任务执行worker数量根据下游模型和工具的承载能力来定。每个任务的状态独立存储worker崩了任务能重新入队。对下游调用做统一的限流和熔断防止一个慢工具拖垮整个池子。这里有个容易忽略的点并发控制要分层做。任务级并发、模型调用级并发、工具调用级并发三层的限流阈值要分别设置。我见过只做了任务级限流结果一百个任务同时打同一个外部API直接把对方打挂的情况。还有一个坑是上下文的内存占用。Agent的上下文动辄几万token一百个并发任务同时持有上下文内存消耗非常可观。我的做法是上下文不常驻内存用完即序列化落盘需要时再加载。牺牲一点延迟换内存安全。3.2 单任务成本必须算到骨头里Agent的成本结构比传统SaaS复杂得多因为它同时消耗推理资源和工具资源。我一般按这个公式拆单任务成本 模型推理成本 工具调用成本 存储与计算成本 失败兜底成本模型推理成本最好算输入输出token乘以单价。但要注意Agent任务往往是多轮推理一轮任务可能调五六次模型成本是单次问答的好几倍。工具调用成本容易被低估。有些外部API是按次收费的Agent如果规划能力差反复调同一个工具成本会失控。我的做法是给每个任务设工具调用次数上限超了就中断并告警。失败兜底成本是最隐蔽的。一个失败的任务要么重试成本翻倍要么转人工人力成本。如果失败率是10%那这10%的成本要摊到所有任务上。所以降低失败率本身就是降本。我做过一个粗略的测算一个中等复杂度的Agent任务如果成功率从80%提到95%单任务综合成本能降30%以上。提升成功率比优化token单价更划算这个结论我验证过好几次。3.3 安全护栏要在设计阶段就焊死Agent能自己调工具、自己执行动作这意味着它的破坏力远大于一个只会聊天的模型。安全护栏不能事后补必须设计阶段就焊死。我的护栏分四层输入层过滤恶意指令、越权请求、注入攻击。特别是当Agent会读取外部内容时要防止外部内容里藏指令劫持Agent行为。决策层对Agent规划出的动作做校验高危动作删除、转账、对外发送必须走二次确认或人工审批。执行层工具调用做权限最小化Agent只能调它被授权的工具且工具本身要有参数校验。输出层对Agent的产出做合规校验防止泄露敏感信息或生成不当内容。这四层里决策层的二次确认机制最关键也最难做。做太严Agent的自动化价值就没了做太松风险兜不住。我的经验是按动作的可逆性来分级可逆动作查询、草稿直接放行不可逆动作删除、发送、支付强制确认。这样既保住了大部分自动化收益又守住了底线。4. 从Agentic Coding到多Agent协作能力边界的真实推演热词里agentic coding、多AI协作、agent框架这些词出现频率很高说明大家都在往这个方向探。我结合自己的实践聊聊这些能力到底能走到哪一步。4.1 Agentic Coding改变了什么没改变什么Agentic Coding简单说就是让Agent自己写代码、自己调试、自己迭代。这个方向确实在快速进步我日常也在用效率提升是实打实的。但它改变的是编码这个环节的效率没有改变定义问题和验收结果这两个环节。Agent能帮你把一个明确的需求实现出来但需求本身是否合理、边界是否清晰、验收标准是什么这些还得人来定。我见过太多团队指望Agent自动搞定一切结果需求本身是模糊的Agent产出的东西看着像那么回事一验收全是坑。所以我的用法是把Agent当成一个执行力极强但需要明确指令的初级工程师。给它清晰的任务描述、明确的输入输出约定、可运行的测试用例它能干得很漂亮。指令模糊它就自由发挥发挥出来的东西你得花更多时间收拾。4.2 多Agent协作的适用边界多Agent协作听起来很美——让一个Agent规划、一个Agent执行、一个Agent审查互相配合。但我在实践中发现多Agent的收益是有条件的。适合多Agent的场景通常满足两个条件任务可清晰分解且子任务之间耦合度低。比如一个内容生产流程选题Agent、写作Agent、审核Agent各管一段交接物是明确的文本这种就适合。不适合的场景是任务高度耦合、需要频繁来回沟通的。这种场景下多Agent之间的通信成本会吃掉协作收益还不如一个能力强的单Agent加一套好的Harness。我踩过的坑是早期迷信多Agent把一个本该单Agent做的任务拆成三个Agent结果三个Agent之间来回传上下文token消耗翻了三倍成功率反而降了。后来合并回单Agent加了更完善的Harness效果立刻好转。多Agent不是银弹它是特定场景下的优化手段不是默认架构。4.3 Agent框架选型的几个务实考量框架选型上我的建议是别被功能最全迷惑要看最贴合你的Harness需求。考量维度关键问题我的倾向状态管理是否原生支持任务持久化和恢复必须有否则生产不可用可观测性是否提供完整的执行轨迹必须有否则无法调优工具集成接入自定义工具的难度越简单越好减少胶水代码并发模型是否支持任务级隔离必须有否则并发会互相污染社区活跃度出问题能否快速找到答案重要但不作为首要标准我个人的经验是框架能覆盖80%的通用需求就够了剩下20%的业务特异性需求靠自己在Harness层扩展。指望一个框架解决所有问题最后往往是被框架的抽象绑住手脚。5. 软件公司该怎么重新算这笔账回到标题那句话——软件公司的价值要重新计算了。怎么算我给一套我自己在用的思路。5.1 先算清楚你的任务资产传统SaaS公司盘点的是功能清单Agent时代要盘点的是任务资产。也就是你的产品到底能替客户完成哪些任务每个任务的替代率、成功率、单任务成本是多少。这个盘点做完你会得到一张任务价值表。表里ROI高的任务就是你应该优先Agent化的方向ROI低甚至为负的先别碰。很多公司一上来就想做全能Agent结果每个任务都做得半吊子成功率上不去成本下不来客户用两次就跑了。聚焦是Agent时代最重要的产品策略。与其做十个成功率60%的任务不如做一个成功率95%的任务。5.2 定价要跟着价值走不是跟着成本走成本加成定价在Agent时代会吃大亏。因为Agent的价值不是线性的——一个成功率95%的Agent客户愿意付的价格可能是成功率70%的Agent的三倍但两者的成本差距可能只有30%。所以定价要锚定客户感知的价值而不是你的成本。客户感知的价值来自这个任务我自己做要花多少人力、多少时间、多少出错成本。你的定价只要显著低于这个数客户就有动力买单。我一般会做一次客户侧的ROI测算把人工完成成本和Agent完成成本摆在一起给客户看。这个对比越清晰成交越顺。5.3 组织能力也要跟着重算最后说一个容易被忽略的点Agent化不只是产品和技术的事组织能力也得跟着变。传统SaaS公司的核心能力是产品设计和工程实现。Agent时代核心能力变成了三样场景理解能力知道哪些任务值得Agent化、Harness工程能力把Agent做得可靠可控、效果运营能力持续监控成功率、成本、客户满意度并迭代。这三样能力里场景理解和效果运营是很多技术型公司欠缺的。我见过技术很强的团队Harness做得漂亮但选错了场景做出来的Agent没人用。也见过场景选得准的团队但Harness太糙成功率上不去客户流失。所以我的建议是Agent化转型要三管齐下别只盯着技术。技术是基础但决定成败的往往是场景选择和持续运营。我在实际推进这类项目时最大的体会是别把Agent当成一个功能来做把它当成一个数字员工来运营。功能上线就完事了员工是要持续培训、考核、优化的。这个心态的转变比任何技术选型都重要。你得像管人一样管你的Agent——给它清晰的职责、明确的考核标准、持续的反馈迭代它才能真正替你创造价值。那些把Agent当功能做的团队最后大多停在demo阶段把它当员工运营的才真正跑出了商业闭环。