实战拆解｜Agent 落地第一站：办公助手如何从聊天走向业务执行

最近这一轮 Agent 热度，和前两年的 AI 聊天不太一样。

以前大家更关心的是，它能不能回答得更准，能不能写文案，能不能写代码。

现在问题往后走了一步。

如果 Agent 不只是回答，而是开始接工具、调系统、执行操作，那它到底能做什么？不能做什么？谁来判断它有没有权限？执行前要不要确认？执行后出了问题，又该怎么追溯？

我们做通用 Agent 平台的第一个落地应用时，选择了办公助手。

不是因为办公助手最酷。

而是因为它刚好能验证一个很现实的问题：

企业内部 Agent 想从聊天走向业务执行，中间到底缺哪些工程机制。

这篇文章复盘的，就是办公助手从自然语言入口，逐步接入业务能力、权限校验、二次确认和 workflow 的过程。

后台能力很多，但人还是会被流程卡住

很多内部系统的问题，不是“没有能力”。

恰恰相反，能力往往已经很多。

运营后台、活动后台、数据平台、配置系统、内部工具平台，每个系统都有自己的入口、菜单、字段和操作习惯。

熟手处理一个问题很快，不一定是因为点得快，而是因为他知道：

去哪个后台查；
用哪个入口；
参数怎么整理；
查完以后下一步看什么；
哪些操作需要谨慎确认。

新手慢，也不一定是不努力。

他只是还没建立那张隐形地图。查一个不会的，又冒出一串不会的；一个入口找不到，又要问下一个入口。

所以办公助手要解决的，不是“系统有没有能力”，而是“人怎么把这些能力串起来用完”。

从这个角度看，办公助手不是把后台换成聊天框。

它要做的是把原来依赖熟手经验的处理链路，沉淀成 Agent 可以理解、可以调用、可以确认、可以审计的业务流程。

办公助手不是“后台聊天入口”

做办公助手时，最容易走偏的一条路，是把它理解成“后台的聊天入口”。

也就是把原来在页面里点的功能，换成一句话让 Agent 调用。

这个方向看起来直接，但风险很大。

企业内部后台不是公开搜索引擎。它背后有权限、上下文、业务规则、操作风险和审计要求。

有些动作只是查询，出错最多是结果不准。

有些动作涉及状态变更，出错就可能影响真实业务流程。

所以我们更关注几个问题：

哪些动作是高频、常用、可闭环的；
哪些步骤可以由 Agent 辅助判断；
哪些操作必须经过权限校验；
哪些执行前必须让人二次确认；
哪些过程需要留下审计记录。

换句话说，办公助手真正要做的，不是给模型更多后台能力，而是把业务处理方式从“靠人记住路径”升级为“由 Agent 按受控流程执行”。

前者只是换入口。

后者才是工程化。

从查询到执行，先用三个场景验证

办公助手第一阶段没有追求覆盖所有后台。

我们先选了三类场景，不是因为它们最复杂，而是因为它们最能说明问题。

它们刚好对应企业内部 Agent 落地时最容易卡住的三件事：

查一个对象，能不能连续追问，而不是每次都重新找入口；
做一次写操作，能不能先确认再执行，而不是听懂了就直接动手；
生成一段内容之后，能不能继续进入发送、确认和结果回传，而不是停在文案生成。

对象查询

过去这类问题的麻烦，不在“查不到”。

而在于用户问的是一个对象，人脑要拆成好几步：

先查基础信息；
再查关联关系；
需要时继续查状态信息；
查完还要自己判断下一步该看什么。

每一步都可能对应不同后台、不同入口、不同字段。

所以原来的工作方式是：人围着系统转。

接入办公助手后，变化不是“少点了几个按钮”这么简单。

图里能看到，用户先输入一个对象 ID，Agent 返回基础信息；用户继续追问状态信息，Agent 可以沿着同一个对象继续查，并把结果补回来。

这时候人的工作方式变成了：围绕一个对象连续追问，系统负责把背后的链路串起来。

这里真正变化的，不只是少打开几个页面，而是同一个对象的连续追问被放进了一条对话链路里。

批量操作

这个场景的对比更明显。

过去做一次批量操作，难点不只是填表。

图里可以看到，原来的后台表单里有对象、操作项、时间、开关、备注等多个字段。

后面是 Agent 加持后的过程。用户先用一句话描述目标，Agent 把操作对象、操作内容和执行参数整理成确认信息。用户确认后，Agent 才继续执行，最后返回结果汇总：成功 12，失败 0。

批量操作 Agent 加持后效果图：

把两张图放在一起看，真正耗人的地方就更明显了：

对象要整理；
操作项要确认；
参数要填对；
有效期要设置；
执行前要确认范围；
执行后还要看结果。

也就是说，它看起来是一次“提交”，实际是一条完整的操作链路。

这组图能说明一个很重要的点：

办公助手不是把“执行按钮”搬进聊天框。

它是把“识别对象、整理参数、二次确认、执行、返回汇总”组织成了一个受控 workflow。

原来的体感是：人在后台里反复确认。

现在的体感是：Agent 先整理，人确认关键动作，系统再执行。

运营提醒类文案辅助

这个场景很容易被误解成“让 AI 写一段文案”。

但实际不是。

过去这类操作也不是只写文案。

图里，原流程需要在后台表单里填写分类、对象 ID、标题、内容、提醒等级等字段。

Agent加持后，用户先让办公助手基于对象状态生成提醒文案。用户确认文案后，Agent 再进入二次确认。确认后才执行发送。发送完成后，还可以继续追问这个对象的其他信息。

运营提醒文案 Agent 加持后效果图：

这两张图放在一起看，对比其实很关键。

过去是：写文案、填表单、点发送、再回头查信息。

现在是：生成文案、确认内容、确认发送、返回结果、继续追问。

也就是说，人不再需要同时完成三件事：

判断该发什么；
写出合适的表达；
在后台里把发送参数填完整。

Agent 不是只完成了“生成”，而是把生成之后的确认、执行和后续查询也串了起来。

这三个场景共同指向一个判断：

办公助手不是一个单点工具，而是一组围绕真实工作流展开的业务能力。

它要解决的不是“能不能查到”，也不是“能不能调一次接口”，而是“能不能把一次处理过程稳定做完”。

架构上，把理解、编排和执行分开

为了让办公助手不变成失控的万能入口，我们在架构上做了分层。

用户入口负责承接消息和身份。
通用 Agent 平台负责理解意图、维护会话、加载 Skill，并决定是否需要调用工具。
Skill 负责把业务能力组织成模型可理解、也可维护的知识和流程。
Gateway 位于 Agent 和业务系统之间，负责鉴权、适配、二次确认、审计和下游调用。
最后才是各个业务系统，只暴露被允许、被约束、可追踪的能力。

如果把一次请求展开，它大概会经历这样一条链路：入口承接消息，通用Agent 平台维护会话和加载 Skill，CLI 触发工具调用，Gateway 做身份与权限校验，再把请求转给具体业务系统。

这里最重要的一点，是不要让通用 Agent 直接面对所有内部系统。

Agent 擅长理解自然语言、组织上下文、判断下一步动作，但它不应该绕过权限系统，不应该直接拼内部接口，也不应该对高风险操作拥有默认执行权。

所以 Gateway 不是简单转发层，而是受控执行层。

它要回答几个问题：

这个人有没有权限使用这个能力；
这个动作是否需要二次确认；
下游系统协议是否需要适配；
执行结果应该怎样返回给 Agent；
操作过程是否需要留下审计记录。

这个设计让办公助手可以继续扩展，但扩展不是无边界的。

每新增一个能力，都要先被描述、授权、接入、确认和审计，而不是临时把一个后台接口塞给模型。

Skill 不是文档，是业务能力的组织方式

办公助手里另一个关键点，是 Skill。

很多人第一次听到 Skill，容易把它理解成“给模型看的说明文档”。

但在这个项目里，Skill 更像业务能力的组织方式。

如果把所有能力写在一份大文档里，模型很快会遇到两个问题。

一是上下文膨胀。能力越多，命中越不稳定。

二是业务边界模糊。今天加一个查询能力，明天加一个批量操作，后天再加一个提醒流程，如果没有分层，后续维护会越来越难。

所以办公助手没有简单按后台系统拆能力，而是尽量按用户问题和业务对象拆。

可以简单理解成几层：

根 Skill 做总分诊，先判断用户问题的大方向；
领域文档判断具体业务域，缩小上下文范围；
Tool 承接单个原子能力；
Workflow 承接多步任务闭环；
写操作再走 confirmation，也就是二次确认。

这套结构的意义，是让 Agent 不需要一次性“知道所有事”。

它只需要在当前任务里加载必要信息，按业务流程逐步往下走。

这比把所有后台能力摊开给模型稳定得多。

如果把这套分层展开成配置，核心思路大概是这样。

根 Skill 不负责塞满所有工具，而是先做路由，让模型按任务选择当前需要加载的领域能力：

markdown
 
## Loading Order
 
1. Read this root file to understand runtime rules and domain routing.
2. Pick one domain according to the user's intent:
   - domains/object/DOMAIN.md: object query and related status.
   - domains/ops/DOMAIN.md: confirmation-based write operations.
   - domains/message/DOMAIN.md: message generation and sending flow.
3. Read the domain's referenced tools/*.yaml file.
4. If the matched tool has `requires_confirmation: true`,
   read common/confirmation.md.
5. If the gateway returns an auth error,
   read common/auth-errors.md.

这样做的好处是，模型每次只读当前任务需要的那条路径，其他领域的 Tool 不进入上下文。

对于只读查询类能力，Tool 更像一个清晰的原子能力说明：

yaml
tools:
  - name: query_object_profile
    description: Query object profile through the gateway.
    permission_scope: object.profile.read
    gateway_route: object.profile.query
    requires_confirmation: false
    request:
      type: object
      required: [object_id]
      properties:
        object_id:
          type: string
          description: Business object id.
    response:
      data:
        type: object
        properties:
          object_id:
            type: string
          display_name:
            type: string
          status:
            type: string

写操作则必须显式标记需要确认。

这个字段很小，但它决定了 Agent 能不能从“会调工具”走向“受控执行”：

yaml
tools:
  - name: execute_controlled_action
    description: Execute a controlled action after human confirmation.
    permission_scope: object.action.write
    gateway_route: object.action.execute
    requires_confirmation: true
    request:
      type: object
      required: [object_ids, action_type, params]
      properties:
        object_ids:
          type: array
          items:
            type: string
          description: Business object ids.
        action_type:
          type: string
          description: Controlled action type.
        params:
          type: object
          description: Action parameters.

确认流程本身也要被写清楚。

否则模型很容易跳过关键步骤，直接把“用户想做什么”误当成“用户已经确认执行”：

markdown
1. Call execute with --requires-confirmation.
2. Show the returned preview to the human operator.
3. If approved, call confirm with the returned confirm_id.
4. Return execution result and summary to the user.

读写 Tool 的差别，表面上只是requires_confirmation这个字段。

但工程上的意义很大。

它把“模型决定做什么”和“人确认是否执行”拆开了，也让 Gateway 可以统一处理确认、审计和结果回传。

我们刻意没有追求覆盖所有后台

企业内部 Agent 很容易陷入一个诱惑：

既然能接工具，那是不是应该把所有接口都接进去？

我们的判断是，不应该。

至少在办公助手这个阶段，不应该。

原因不是技术做不到，而是很多场景不适合直接交给 Agent 执行。

强交互场景不适合简单封装成一次工具调用。

长事务场景需要更完整的状态管理。

复杂状态机场景需要业务系统本身提供严格约束。

重业务上下文授权场景，也不能直接塞进通用 Gateway。

这些边界必须提前说清楚。

因为 Agent 一旦进入执行层，它的风险和普通问答完全不一样。

普通问答答错了，最多是信息不准。

执行动作出错，就可能影响真实业务流程。

所以我们更愿意先接高频、常用、可闭环、风险可控的场景。

先让 Agent 稳定完成真实任务，再逐步扩大边界。

这比一开始追求能力覆盖率更重要。

这次实践验证了什么

回头看办公助手这个项目，它验证的不是“我们又做了一个 AI 应用”。

它更像是通用 Agent 平台进入真实业务系统的第一站。

这一步至少验证了三件事。

企业内部 Agent 的入口可以很自然。用户不需要记住后台路径，也不需要先判断自己该去哪套系统里找能力，通过企业 IM 或通用 Chat 入口，就可以用自然语言发起查询和处理。
业务能力不能直接交给模型裸调。中间必须有 Gateway，有权限校验，有二次确认，有可追溯的执行记录。否则能力越多，风险越高。
Skill 和 Workflow 是让 Agent 稳定工作的关键资产。没有它们，模型面对的是一堆分散能力；有了它们，模型面对的是按业务对象、任务类型和执行流程组织好的能力体系。

所以办公助手不是替代人，而是在降低熟手经验的复制成本。

哪些问题先查什么，哪些场景下一步看什么，哪些动作需要确认，哪些结果需要提醒，这些都可以逐渐沉淀到 Skill 和 Workflow 里。

结语

企业内部 Agent 真正落地以后，问题会变得很具体。

不是模型够不够聪明。

而是它能不能理解业务问题，能不能找到正确能力，能不能在权限范围内执行，能不能在关键动作前让人确认，能不能在执行后留下记录。

办公助手这次实践给我们的一个判断是：

Agent 的价值，不在于让模型拥有更多后台能力，而在于把后台能力组织成更稳定、更安全、更可复用的业务流程。

AI 从聊天走向执行，中间隔着的不是一句 prompt。

而是一整套工程机制。

**花椒技术交流群
**

还在孤军研究 AI 工程化、AI 编程、Agent 落地，没人同行交流、没人拆解实战？

这里汇聚一线技术从业者，专注代码评审、企业内部 AI 助手真实实战落地。

想紧跟 AI 前沿动态、交流工程落地经验、少走踩坑弯路，欢迎直接加入**「花椒技术交流群」**。

群内专属福利拉满：每日精选 AI 行业日报、文章独家延伸资料、文中未展开的技术细节，全部同步共享。

如果二维码过期，可在私信回复**「技术群」** 获取最新入群入口。

实战拆解｜Agent 落地第一站：办公助手如何从聊天走向业务执行

相似文章推荐

评论 (0)