Bot 时代来了？从能力封装到数字员工，AI Agent 正在发生什么变化

最近AI Agent 领域出现了一个值得关注的变化越来越多的讨论开始从 Skills 转向 Bot。过去我们关注如何给大模型增加能力设计 Prompt、封装 Skills、接入 MCP、编排 Workflow。现在新的问题开始出现能不能让 AI 不只是执行一次任务而是拥有自己的身份、职责、记忆和执行环境持续承担某项工作例如一个合同审查 Skill可以帮助模型完成合同风险识别但一个企业法务 Bot不仅可以审查合同还能查询企业法律知识库、跟踪审核任务、调用外部系统并在必要时请求律师介入。两者看起来都使用了 Agent 技术但产品形态和工程架构已经有了明显区别。我的一个判断是Skills 并没有消失但 AI 应用正在从以能力为中心转向以 Bot 为中心。这不是简单的概念升级而是 AI 应用从工具化向任务执行系统演进的一种表现。本文尝试从技术架构、工程实现和商业模式三个角度分析这一变化。一、Skills 和 Bot到底有什么区别先看一个具体例子合同审查。传统的合同审查 Skill通常包含合同文本提取合同主体识别关键条款分析违约责任检查风险条款识别审查报告生成它把专业知识、任务指令和执行步骤封装成一个可复用的能力模块。用户提出请求模型根据任务选择相应 Skill然后执行并返回结果。它解决的是这样一个问题如何让 AI 可靠地完成某一类任务现在换一种思路。我们设计一个企业法务 Bot。它除了合同审查还可以接收企业员工的法律咨询。判断问题属于合同、劳动关系还是知识产权。检索企业内部法律知识库。根据任务调用合同审查 Skill。查询外部法规和相关案例。生成初步分析意见。对高风险事项提交律师审核。记录审核结果和后续待办。持续跟踪未完成的任务。此时合同审查只是这个 Bot 拥有的一项能力。它还需要知道自己是谁、负责什么、能够访问哪些系统、当前有哪些任务以及哪些事情必须交给人来处理。这就是两者最重要的区别。对比维度SkillsBot核心定位可复用的能力模块持续工作的智能角色主要解决如何完成某项任务如何承担一类工作生命周期按需加载和执行可以持续存在状态管理通常较简单需要任务状态管理记忆可选通常需要工具调用提供能力和使用规范负责组织和调度业务边界单项能力一组职责和业务目标商业形态能力包、工具AI 员工、数字岗位这里需要注意Skills 和 Bot 并不是同一层级的竞争关系。Skill 更像是一个专业能力模块而 Bot 则是组织和使用这些能力的上层实体。因此与其说 Bot 替代 Skills不如说Skills 正在从 AI 应用的核心产品形态转变为 Bot 的基础能力资产。二、AI 应用正在经历怎样的架构演进从工程角度看可以把 AI 应用的发展归纳为五个阶段。1. Prompt 时代让模型理解任务早期 AI 应用主要依赖 Prompt Engineering。通过角色设定、任务描述、输出格式和示例引导模型完成特定工作。典型形态用户输入 ↓ Prompt ↓ LLM ↓ 结果输出优点是简单、开发成本低。缺点也很明显复杂任务容易出现不稳定无法直接操作外部系统也缺乏可靠的状态管理。2. Tools 时代让模型能够操作外部系统随着 Function Calling 等能力的发展模型开始能够调用外部工具。例如查询数据库调用业务 API搜索互联网读写文件执行代码MCP 则进一步推动了模型与外部工具、资源之间的标准化连接。AI 不再只是生成内容而是能够执行操作。3. Skills 时代让能力可以复用当单纯的工具调用无法满足复杂业务需求时我们开始把专业知识、操作流程和执行规范封装起来。例如合同审查 Skill ├── 合同解析 ├── 主体识别 ├── 条款分析 ├── 风险识别 └── 报告生成Skills 解决的是专业能力的模块化与复用问题。4. Agent / Bot 时代让 AI 持续承担任务当 AI 能够理解目标、规划步骤、选择能力、调用工具、保存状态并处理异常时它就开始具备承担完整任务的能力。架构从用户请求 ↓ 选择 Skill ↓ 执行任务 ↓ 返回结果演进为用户 / 事件 / 定时任务 ↓ Bot Runtime ↓ 目标解析 ↓ 任务规划 ↓ 能力路由 ↓ Skills Tools MCP ↓ 执行与验证 ↓ 状态持久化 ↓ 完成 / 等待 / 审批最大的变化是过去用户告诉 AI 怎么做现在用户可以直接告诉 Bot 要达到什么目标。当然这并不意味着所有 Bot 都必须完全自主。对于高风险业务人工审批仍然是必要环节。5. Agent Organization从单个 Bot 到数字员工团队当一个 Bot 的工作职责越来越复杂时就可能出现多个 Bot 协同工作的需求。例如企业销售部门销售主管 Bot | ┌─────────┼─────────┐ | | | 接待 Bot 分析 Bot 跟进 Bot | | | 线索收集 客户画像 客户回访 | | | └─────────┼─────────┘ | 结果汇总这已经不只是传统意义上的 Multi-Agent Workflow而是开始接近一个数字员工组织。不过多 Agent 并不是越多越好。如果几个 Agent 之间没有明确的职责边界只是互相传递消息往往会增加系统成本和调试难度。因此应该先从业务职责出发再决定是否拆分 Agent。三、Bot 时代核心技术架构应该是什么如果重新设计一个面向企业的 AI 应用我认为不能只围绕 Prompt、RAG 和 Workflow 展开。需要增加一个重要的架构层Bot Runtime。一个相对完整的 Bot可以拆分为八个部分。1. Identity身份和职责Bot 必须知道自己是谁负责什么以及不能做什么。例如bot:id:contract_assistantname:合同审查助手role:企业合同风险初审responsibilities:-合同信息提取-风险条款识别-法律依据检索-审查意见生成boundaries:-不代替律师作最终法律意见-高风险事项必须人工审核这不仅是角色 Prompt。在生产系统中Identity 还应该关联用户身份、租户、数据访问范围、工具权限和审计主体。2. Goal目标和任务定义Bot 不能只接收自然语言还需要把用户目标转换成可执行、可检查和可追踪的任务。例如{task_id:task_001,goal:完成采购合同初审,status:running,steps:[提取合同信息,识别风险条款,检索法律依据,生成审查意见]}目标必须尽可能明确。否则模型即使执行了很多步骤也不一定意味着完成了用户真正需要的工作。3. Brain理解、规划和决策Brain 可以理解为 Bot 的决策层。主要负责意图识别任务分解执行规划Skills 选择工具路由异常判断结果验证LLM 是 Brain 的重要组成部分但不能把所有决策都交给模型。涉及权限、预算、审批和业务规则的判断应该尽可能由确定性的程序逻辑约束。4. Skills专业能力Skills 仍然非常重要。例如legal_bot/ skills/ contract_review/ labor_law_consulting/ legal_document/ regulation_search/每个 Skill 可以包含专业知识执行指令工作步骤输入输出规范工具使用要求质量检查规则Skill 的价值在于让专业能力可复用、可维护、可组合。5. Tools外部工具和系统连接Bot 必须能够连接真实业务系统。例如企业 CRMERPOA数据库文件系统邮件系统浏览器第三方业务 APIMCP 可以帮助标准化工具接入但并不意味着所有工具都必须通过 MCP 实现。对于企业生产环境API、权限认证、数据隔离和调用审计同样重要。6. Memory记忆和业务上下文普通聊天机器人主要依赖对话历史。真正的 Bot 需要管理更多类型的信息。类型示例Profile Memory企业客户基本信息Episodic Memory历史任务和执行结果Semantic Memory企业知识、业务规则Procedural Memory工作流程和操作经验Task State当前任务执行进度这里需要区分一个概念对话历史不等于业务记忆。例如销售 Bot 不仅要记住客户说过什么还应该知道客户目前处于哪个销售阶段上次沟通承诺了什么当前有哪些待办事项下一步应该执行什么操作这才是面向业务的记忆系统。7. Runtime执行环境和生命周期管理这是 Bot 从 Demo 走向生产环境的关键。Runtime 负责任务调度状态管理执行循环超时与重试断点恢复工具调用人工审批任务取消运行日志一个真正可商用的 Bot不能只是一个不断调用 LLM 的循环。它需要有明确的状态机。例如CREATED ↓ PLANNING ↓ RUNNING ↓ WAITING_APPROVAL ↓ RUNNING ↓ COMPLETED 异常情况 RUNNING → FAILED RUNNING → RETRYING RUNNING → CANCELLED尤其是长任务必须考虑进程重启、重复执行、部分成功和外部系统调用失败等问题。8. Governance权限、安全和可观测性Bot 能够执行的操作越多权限和安全就越重要。例如哪些数据可以读取哪些系统可以访问哪些操作需要人工审批是否允许自动发送邮件是否允许修改业务数据如何追踪一次任务的完整执行过程如何评估任务成功率和调用成本这些不是上线之后再补充的功能而应是架构设计的一部分。四、Bot 时代真正的技术壁垒在哪里过去开发一个 AI 应用很多团队会把重点放在模型选择、Prompt 优化和 RAG 检索效果上。这些仍然重要但随着基础模型和开发框架不断成熟单纯依靠这些能力建立长期优势会越来越困难。我认为未来的技术价值会更多集中在以下几个方向。技术方向核心价值Agent Runtime可靠执行复杂任务Context Engineering管理任务所需上下文Memory Engineering积累长期业务记忆Tools / MCP连接真实业务系统Skills Engineering沉淀可复用专业能力Agent Evaluation衡量任务完成质量Governance权限、安全和责任控制其中Agent Evaluation 尤其容易被低估。一个 Bot 能够生成看起来合理的结果不代表它真正完成了工作。例如一个销售跟进 Bot是否正确识别客户意向是否按要求查询 CRM是否完成了规定的跟进操作是否错误修改了客户信息是否产生了有效销售线索这些指标比单纯评价回答是否流畅更为重要。未来企业评估 Bot核心应该从回答质量逐步扩展到任务成功率、业务效果、可靠性和单位任务成本。五、Bot 时代AI 产品的商业模式也会发生变化技术架构的变化最终会影响产品的交付方式。过去AI 产品通常销售模型能力软件功能Prompt 模板SkillsWorkflowBot 时代可能出现另一种商业模式直接向企业交付能够承担具体工作的 AI 员工。以 AI 客服为例。传统方式是销售一个 AI 客服软件企业需要自行配置知识库、工作流和各种业务接口。新的方式则是交付一个 AI 客服 Bot自动接待客户。识别客户意图。查询订单和业务信息。处理常见问题。识别高意向客户。转交人工销售。记录客户互动。跟踪未完成事项。企业真正关心的就不再是系统里有多少个功能而是每个月接待多少客户有多少问题被自动解决有多少有效线索能够节省多少人工时间出现问题时能否追溯因此AI 产品的收费单位可能从功能模块、Token 和调用次数逐步向岗位、任务量和业务价值迁移。这里也存在一个现实问题Bot 并不天然比软件更容易收费。只有当它能够稳定完成工作并且实际创造的价值高于部署和运营成本时企业才有持续付费的动力。六、Bot 时代三个容易被忽略的问题1. 不是每个功能都应该做成一个 Bot如果把文本分类、内容生成、知识检索、数据分析都做成独立 Bot系统很容易陷入 Bot 泛滥。更合理的方式是以业务职责划分 Bot以专业能力划分 Skills以外部操作划分 Tools。例如客户接待 Bot 是一个业务角色意图分类、知识检索、客户信息提取则是它使用的能力。2. 自主性越强不代表系统越可靠一个 Bot 拥有更多工具、更长的执行链和更大的自主权也意味着潜在风险更高。可以按照操作风险设计权限等级等级能力示例L1只读和建议查询客户资料L2生成待审核操作生成合同修改建议L3审批后执行审核后发送邮件L4授权范围内自主执行自动发送标准通知对于法律、医疗、金融等高风险场景必须明确人工审核和责任边界。3. Bot 的护城河不在模型而在业务闭环假设两个团队都使用同一个大模型。A 团队开发了一个合同审查 Bot可以识别风险条款。B 团队开发了一个企业法务 Bot除了风险识别还拥有企业历史合同企业法务规则历史审核记录合同审批流程法规更新机制律师审核入口风险跟踪系统两者的差异已经不再是 Prompt而是业务数据、执行流程、权限管理和长期积累的经验。未来 Bot 的核心竞争力很可能来自它所嵌入的业务系统而不是它调用了哪个模型。七、对个人开发者和小团队有什么机会我认为Bot 时代不一定只是大公司的专属机会。对于小团队而言通用 Agent 平台竞争激烈但垂直行业 Bot 仍然有很多值得探索的方向。例如法律 Bot合同审查、法律文书辅助、案件资料整理。财务 Bot票据处理、财务数据整理、经营分析。营销 Bot内容生产、客户线索识别、营销效果跟踪。销售 Bot客户接待、商机分析、销售跟进。文档 Bot企业知识检索、报告生成、标书辅助。这些场景的共同点是这些场景有明确的业务对象、相对固定的工作流程、可量化的交付结果以及明确的付费主体。对小团队来说我更建议先做一个真正能够完成工作的垂直 Bot再逐步抽象通用能力而不是一开始就开发一个通用 Agent 平台。例如一个销售跟进 Bot可以先实现客户信息输入 ↓ 客户画像分析 ↓ 跟进策略生成 ↓ 人工确认 ↓ CRM 数据更新 ↓ 跟进提醒 ↓ 结果记录先把这套流程做稳定再考虑增加客户接待、商机预测和多 Bot 协作。这样更容易验证客户需求也更容易形成可交付的产品。八、AIVA从可见度检测工具到 GEO 运营 Bot以我正在研究的 AIVA 为例。当前 AIVA 的核心流程是品牌信息 ↓ Brand Agent ↓ 品牌画像确认 ↓ Query Agent ↓ Query Set ↓ 模型检测 ↓ 可见度分析 ↓ 报告生成它已经具备比较完整的检测和报告生成链路。但如果从 Bot 的角度重新思考AIVA 还可以进一步演进。未来的 GEO Visibility Bot 可以承担品牌信息维护持续维护品牌画像、产品信息和竞争对手。检测计划管理根据行业、品牌和目标市场制定 Query 检测计划。定期检测按周期检测不同模型、不同联网模式下的品牌表现。异常监控发现品牌提及率、引用率和推荐位置变化。竞争分析发现竞争品牌的表现变化。优化建议生成内容、品牌资料和官网信息优化建议。效果复测执行优化后重新检测评估变化。这样AIVA 就不再只是一个报告生成器而是逐步演进为 GEO 运营辅助 Bot。当然它不应该承诺能够操纵大模型的推荐结果。更合理的定位是检测 → 诊断 → 建议 → 执行协助 → 复测 → 效果评估。工程上也不需要推倒重来。可以先把现有品牌提取、Query 生成、模型检测、指标计算和报告生成封装为 Skills再逐步增加任务调度、历史数据、监控和复测能力。九、总结Skills 没有结束Bot 正在成为新的组织形式回到文章标题。我并不认为 Skills 时代真正结束了。Skills 仍然是 Agent 体系中非常重要的能力资产只是它不再需要独立承担整个 AI 产品的角色。可以用一个简单的公式理解 BotBot Identity Goal Brain Skills Tools Memory Runtime Governance其中Identity我是谁负责什么。Goal我要完成什么工作。Brain我如何理解和规划任务。Skills我具备哪些专业能力。Tools我能够操作哪些外部系统。Memory我记住了哪些业务信息。Runtime我如何执行、恢复和管理任务。Governance我有哪些权限如何保证安全。真正的 Bot是这些能力组合起来能够持续承担工作职责的系统。从技术发展看AI 正在从 Copilot辅助人工作逐渐走向 Coworker与人协同工作甚至在明确授权的范围内成为能够独立执行任务的数字员工。对开发者来说值得研究的已经不只是如何写好一个 Skill而是如何构建一个可靠、可控、可评估、可持续运行的 Bot。对创业者来说机会也许不在于开发更多的 AI 工具而在于找到一个企业愿意付费的岗位把它真正做成一个能工作的 AI 员工。未来企业购买的可能不再只是 AI 能力而是 AI 完成工作的结果。这或许才是从 Skills 到 Bot最值得关注的变化。