Agent 实施不是”部署”，是一条工程链路
很多企业客户对 Agent 的想象还停留在”装个软件”。实际的落地是一条七段式工程链路：
咨询评估 → 方案设计 → PoC 验证 → 开发配置 → 测试 → 试运行 → 运维迭代
周期视复杂度 2 周到 3 个月。跳过任何一段，后面都会加倍还回来。
第一步最关键：调研评估
很多项目死在第一步。调研阶段要弄清楚四件事：
- 业务目标：哪些工作是重复劳动？耗时多少？哪些环节易出错？
- 系统资产：业务系统清单、有没有 API、无 API 系统的页面结构、账号权限与登录方式
- 安全合规：数据能否出客户内网、操作日志审计、数据脱敏、人工审批节点
- 任务分级：只读任务（拉报表、截图巡检、文档提取）和写数据任务（新增表单、提交单据）必须分开对待——前者低风险好落地，后者高风险需要人在回路
同时要划定边界：哪些系统不纳入本期、系统改版后的维护归属。边界不清，后面全是扯皮。
方案设计定四件事
- 入口：飞书 / 钉钉 IM / 业务系统侧边栏 / 定时后台
- 执行方式：优先 API 对接，无 API 时用网页自动化兜底
- 权限与审批流：哪些动作自动执行，哪些必须人工复核
- Agent 架构：知识库 RAG、工具集、记忆策略、日志审计
PoC 几乎是必做题
B 端客户几乎都会要求 PoC：小范围、单一简单场景、不做全量。比如”每日自动登录业务系统 → 抓取数据 → 生成巡检报表 → 推送飞书群”。
PoC 要验证三件事：登录与页面定位的稳定性、大模型输出质量、客户业务人员的接受度。一般 1-4 周，跑通了客户才签正式项目。
上线之后：灰度、告警、运维
不全量放开。先开放给 2-3 个业务人员试运行 1-4 周，收集报错、幻觉、定位失效问题，同步搭建告警（任务失败自动截图推送）。
正式上线后进入运维迭代：任务成功率监控、token 消耗、脚本有效性巡检（提前发现页面 DOM 微小改动）。合同里要写清：客户系统改版带来的脚本修改属于增值服务，单独收费。
场景分三梯队，接单从低风险开始
- ✅ 第一梯队（只读、低风险，优先接）：页面自动化巡检、工单摘要、文档批量处理、跨系统报表合并
- ⚠️ 第二梯队（中等风险，人在回路）：表单辅助录入（Agent 填单、人工核对提交）、客户资料归档
- ❌ 第三梯队（高风险，谨慎）：全自动新增/修改业务单据、发起审批——出错直接造成业务损失，初期不碰
常见的坑
- 客户预期拉满，以为 Agent 能处理所有异常——PoC 阶段就把边界讲清
- Agent 账号权限过大，越权风险——最小权限原则，用独立账号
- 合同边界模糊，客户系统改版要求免费无限改脚本
- 忽略验证码 / SSO / 登录会话过期，脚本跑几天就失效
- 审计缺失——企业客户要完整操作日志，需要额外做日志存储
交付模式的选择
私有化部署：整套部署在客户内网，数据不出域，价格高、周期长，适合大企业。
托管式 OPC：Agent 部署在服务商侧，客户通过 IM / Web 访问，成本低、交付快，适合中小企业。
我的建议：从托管式 OPC 起步，用只读场景建立信任，再逐步深入写数据场景。Agent 服务的生意本质是”持续运维的信任”，不是”一次交付的买卖”。