企业官网建设流程全解析

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任务可能跑几分钟甚至几十分钟，中间要调十几次模型、几十次工具。如果你用传统的"一个请求一个线程"模型，并发一上来线程池瞬间打满。如果你用异步，那状态管理、超时控制、错误传播的复杂度会指数级上升。

我实测下来比较稳的方案是任务队列加工作池的模式：

1. 任务进来先入队，返回一个任务ID，前端轮询或走推送拿结果。
2. 工作池里的worker从队列取任务执行，worker数量根据下游模型和工具的承载能力来定。
3. 每个任务的状态独立存储，worker崩了任务能重新入队。
4. 对下游调用做统一的限流和熔断，防止一个慢工具拖垮整个池子。

这里有个容易忽略的点：并发控制要分层做。任务级并发、模型调用级并发、工具调用级并发，三层的限流阈值要分别设置。我见过只做了任务级限流，结果一百个任务同时打同一个外部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阶段；把它当员工运营的，才真正跑出了商业闭环。