流程、知识与智能体

定制智能体开发与部署

面向拥有独特流程、遗留系统和高风险例外的企业，把智能体从演示原型做成有执行契约、评测基线、人工边界和可回退运行机制的专属生产系统。

不改变的代价问题继续依赖个人经验和人工搬运，投入越多，返工、等待和解释成本也越高。

能力真正解决什么把判断规则、数据证据、岗位动作和系统反馈接起来，让变化进入日常经营。

先把卡点说具体

卡点与痛点

能力建设失败，通常不是模型不够聪明，而是决策、流程、数据和岗位责任没有接起来。这里把问题落到具体环节，也说明它为什么会伤到收入、利润、效率、体验或风险。

业务任务与责任边界

01
专属流程识别
企业知道自己的服务、审批或调度流程很特殊，却没有拆清哪些特殊性产生竞争价值，哪些只是多年补丁。
业务影响开发团队容易把历史绕路全部编码进智能体，投入很大，真正需要保留的差异反而被埋住。
02
任务颗粒度
需求常写成让智能体负责服务运营或合同审核，没有拆成读取、判断、建议、执行、复核和升级动作。
业务影响系统边界无法测试，项目既难估价，也难判断一个错误会影响哪项客户承诺。
03
人工决策权
价格例外、服务赔付、停机风险和客户承诺没有明确由谁最终确认。
业务影响智能体要么只能聊天，无法行动；要么获得过大权限，把一次误判扩散到真实业务。
04
失败处理
方案只描述成功路径，没有定义缺数据、工具超时、权限拒绝、模型不确定和外部系统冲突时怎么停。
业务影响上线后异常会回到临时群聊，工程团队无法稳定复现，业务也不知道何时接管。

工程架构与验证

01
系统接口契约
CRM、ERP、工单、知识库和身份系统各自有字段、限流与状态规则，却被当成普通插件连接。
业务影响写回动作可能重复、乱序或缺少幂等控制，最终形成比人工录入更难追踪的数据事故。
02
模型与工具路由
团队用一个模型处理所有任务，复杂判断、低风险分类和结构化查询没有按成本与可靠性分层。
业务影响简单任务成本过高，关键任务又缺少足够推理、校验和降级路径。
03
评测样本
原型只靠开发者现场提问，没有覆盖历史例外、边界输入、恶意指令和业务规则变化。
业务影响演示通过不能说明生产可用，版本更新后也无法判断质量是否退化。
04
运行可观测性
日志只记录模型回答，不记录输入来源、工具调用、权限判断、人工修改和最终业务状态。
业务影响发生问题时找不到责任链，评测、审计和改进都只能靠猜。

部署运营与经济性

01
发布与回退
智能体直接从测试环境切到全量岗位，没有影子运行、分支灰度、版本锁定和紧急停用。
业务影响小概率错误会同时影响多个团队，业务只能停系统或回到手工补录。
02
长期产品责任
项目上线后由谁维护提示、工具接口、评测集、权限和知识更新没有进入岗位职责。
业务影响几个月后系统仍能打开，却已经不符合新政策、新产品和真实流程。
03
单位任务成本
预算只算模型调用费，没有算集成、人工复核、异常处理、评测和运维值守。
业务影响项目量一上来毛利和运营压力才暴露，管理层难判断继续自建还是调整路线。

从问题到经营变化

企业变化

不只展示“前后对比”，还要说清原问题为什么伤害经营、能力到底做什么，以及变化如何进入日常工作。

常见问题与痛点: 企业从功能愿望出发，把聊天、检索、工具调用和多智能体编排一起塞进范围，开发周期不断增长，业务责任却越来越模糊。
企业收益与提升: 企业得到的是可测试的执行边界，能够按风险分期投入，并知道每一项开发费用在解决什么经营问题。
核心要点: 核心工作先把专属流程拆成任务、状态、权限、证据和失败路径，再决定每一步由规则、模型、系统或人工承担。

常见问题与痛点: 原型依赖开发者现场照看，遇到脏数据、接口超时或例外客户就回到手工，无法作为生产系统排班。
企业收益与提升: 企业可在受控范围内放大任务量，降低事故恢复时间，也能用运行证据决定扩大、降级或换模型。
核心要点: 核心工作建立工具契约、幂等写回、评测集、追踪链路、告警和回退机制，让异常能被复现、分级和接管。

常见问题与痛点: 所有任务调用同一种模型和同一套提示，成本、时延和准确性互相牵制，团队只能在更贵或更不稳之间选择。
企业收益与提升: 企业获得可解释的单位任务成本，并在质量门槛不变时持续优化推理和复核支出。
核心要点: 核心工作按任务风险设计模型路由、规则校验、缓存、结构化工具和人工复核，把高成本能力留给真正需要的判断。

常见问题与痛点: 项目交付被视为上线即结束，业务流程和政策一变，智能体很快失去可信度。
企业收益与提升: 企业形成可长期维护的专属能力，而不是依赖某位工程师记忆的脆弱自动化。
核心要点: 核心工作把版本发布、知识更新、权限审查、失败复盘和业务负责人纳入持续运营。

经验往往藏在反直觉处

我们非共识认知

行业共识能帮项目获得预算，非共识才经常决定项目能不能产生结果。每一条都把市场做法、不同判断、原因和佐证摆在一起。

我们先画决策权与失败路径，再决定是否需要一个或多个智能体。

市场常见做法: 市场常从智能体数量、自治程度和编排拓扑开始设计。
我们的判断: 我们先画决策权与失败路径，再决定是否需要一个或多个智能体。
为什么: 生产风险来自错误动作怎样进入业务，不来自架构图看起来是否先进；能用确定性规则解决的节点不应为了新鲜感增加模型。
佐证案例: 复合案例先定义服务承诺、派工、备件和赔付的人工边界，随后才选择分类、检索、计划与执行组件。

我们把每个工具当成有前置条件、幂等规则、回执和补偿动作的业务契约。

市场常见做法: 市场常把能调用系统视为部署完成。
我们的判断: 我们把每个工具当成有前置条件、幂等规则、回执和补偿动作的业务契约。
为什么: 企业系统不是无状态函数，重复写回、并发修改和状态过期都可能造成真实损失。
佐证案例: 复合案例要求每次工单更新保留事件编号、权限判断、版本和人工确认，并能按事件回放。

我们按任务风险、时延和证据要求做动态模型组合，并保留规则与人工通道。

市场常见做法: 市场常追求一个最强模型覆盖全部岗位。
我们的判断: 我们按任务风险、时延和证据要求做动态模型组合，并保留规则与人工通道。
为什么: 低风险结构化任务不值得支付复杂推理成本，高影响承诺也不能只依赖单次生成。
佐证案例: 复合案例把意图分类、资料汇总、排程建议和赔付审批放在不同可靠性层级验证。

我们认为可回退、可观测、可维护比首次上线日期更能说明工程完成度。

市场常见做法: 市场常把上线速度当成定制项目最重要的证明。
我们的判断: 我们认为可回退、可观测、可维护比首次上线日期更能说明工程完成度。
为什么: 智能体会随数据、模型、接口和规则变化，缺少运营机制的快速上线只是把维护债务推给业务。
佐证案例: 复合案例把影子运行、灰度发布、故障演练和评测集交接列为进入生产的必要条件。

从判断到落地

方法论与解决方案

三张图分别回答机会怎么选、流程怎么改、试点怎么扩。点击图片可查看完整中文标注。

通俗说明：先把智能体要做的每一步、不能做的事和出错后谁接手画清楚。专业说明：按业务事件拆解状态、输入证据、决策权、工具副作用、异常类型和补偿路径，形成架构与评测的共同基线。

专属任务与失败边界图

通俗说明：让模型、规则、系统接口和人工审批各做自己最可靠的部分。专业说明：定义编排器、模型路由、检索、工具契约、身份权限、状态存储和人工任务队列之间的数据与控制关系。

智能体执行契约架构

通俗说明：每次改版本都先考试，小范围上岗，出问题能查清并退回。专业说明：用离线回放、在线质量门槛、灰度发布、全链路追踪、成本监测和事故复盘管理持续变更。

评测、发布与观测循环

不是文件清单

典型交付成果

交付成果必须有人使用、进入真实流程，并改变一个可观察的经营结果。否则它只是换了封面的会议纪要。

把客户请求、合同条件、设备状态、备件可用性和人员排班汇入一个受控执行界面，显示建议、依据和下一动作。

服务运营执行中枢

把客户请求、合同条件、设备状态、备件可用性和人员排班汇入一个受控执行界面，显示建议、依据和下一动作。

谁来使用: 服务调度员、区域主管、技术支持和运营管理者
如何进入日常运营: 系统按事件更新上下文，低风险动作可在规则内执行，高影响承诺进入人工确认队列。
带来的经营价值: 减少跨系统查找和重复转述，让响应速度提高的同时保留客户承诺责任。

按风险展示价格、赔付、停机、数据不足和工具失败事项，并说明智能体为何停下。

人工审批与接管队列