01 不知道该做哪个 Agent
「做个智能客服」「做个 AI 助理」——这类需求最大的风险是方向错：投入三个月做了一个使用频率极低的东西。智能体适合有明确输入、可枚举工具、结果可验证的任务，不适合开放性的模糊目标。
→ 我们的做法： 先做任务可自动化性评估——把候选任务按「输入是否结构化、工具是否可调用、结果是否可验证、出错成本多高」四个维度打分，分数决定先做什么、不做什么。
Service 02 · Agent & Skills
Agent 与 Skills 开发：把 AI 能力构建为可复用的资产
我们基于大模型为企业开发智能体（Agent）——能理解任务、调用工具、多步执行的自动化系统；并把其中可复用的能力封装为技能（Skills）模块——带清晰输入输出契约、文档与测试的标准化组件。
两个层次的关系：Agent 解决「这个业务流程让 AI 自己跑起来」；Skills 解决「跑起来的能力能不能被沉淀下来」。只做 Agent 不做 Skills，每个新需求都要从头开发；能力沉淀成 Skills 后，新智能体是技能的组合，而不是重写。这是「一次性脚本」和「能力平台」的分水岭。
解决什么问题
02 Prompt 散落在聊天记录里，人走能力丢
很多团队的 AI 能力就是几段效果不错的提示词（Prompt），存在个人文档里。换了人就失效，出了问题没人知道为什么。
→ 我们的做法： 把有效能力封装为 Skills——明确的触发条件、输入输出规范、失败时的行为定义，配上版本与变更记录。能力从「某人的经验」变成「团队的组件」。
03 效果不稳，无法验收
模型输出是概率性的，今天测十次全对，下周用户反馈全是错。没有评估体系，验收就变成「感觉还行」。
→ 我们的做法： 每个 Agent 交付时带评估集——一组标注过的测试用例与自动化评估脚本，回归测试不通过就不能上线。效果从「感觉」变成「指标」。
交付流程
- 1
任务评估与选型 1 周
梳理候选业务任务，做可自动化性评估，确定首个智能体的任务边界与成功指标。
产出： 任务评估报告与开发优先级建议。
- 2
架构设计 1 周
设计智能体架构：模型选择、工具与接口清单、记忆与上下文策略、权限边界、失败兜底。
产出： 架构设计文档——含每个组件的技术选型理由。
- 3
开发与评估体系并行 3–6 周
开发智能体本体与所需技能模块，同时构建评估集。开发节奏为每周可用版本，持续对照评估集调优。
产出： 可运行系统 + 评估集与回归脚本。
- 4
交付与能力沉淀 1–2 周
技能模块入库归档（含文档与使用示例），向你的团队做架构讲解与二次开发培训。
产出： 技能库、交接文档、培训记录。
交付物清单
逐项可核对——项目结束时，你拿到的是这些。
- 01
任务评估报告 候选任务的自动化可行性分析，含「不建议做」的部分及理由。
- 02
架构设计文档 模型选型、工具链、上下文与权限策略，及每项选型的理由。
- 03
Agent 系统 源代码、部署配置、系统运行文档。
- 04
技能（Skills）模块库 每个技能含接口定义、输入输出示例、失败行为说明与版本记录。
- 05
评估集与回归脚本 标注测试用例、自动化评估流程，可长期用于效果回归。
- 06
交接文档与培训 架构讲解、二次开发指南、至少一次团队培训。
适合谁 / 不适合谁
诚实的双向筛选：不合适的客户被劝退，比签了做砸更好。
典型的适用场景
- 信息密集型流程：需要跨多个系统查信息、汇总、生成结构化产出的环节（如工单预处理、报告初稿、资料审查）。
- 内部工具的对话式入口：让员工用自然语言操作已有内部系统——前提是这些系统有可调用的接口。
- 高频重复的验证型任务：高频重复、结果可明确判定的任务（如数据核对、格式检查、内容合规初审）。
暂不适用
- 开放性创意决策（品牌战略、核心创意）——模型可以辅助，不能担责。
- 输入完全非结构化且无法定义「合格输出」的任务——验收标准立不起来，项目就会变成无限修改。
- 数据或接口完全封闭、无法集成的环境。