业务系统的 AI 接入：节点增强与任务重构

1. 先分清两个维度

接入基础：利用现有业务系统，还是新建业务系统。
工作方式：在人操作的流程中增加辅助能力，还是围绕目标委派重新设计协作。

两个维度并不互斥。新设计的 Agent 应用可以继续调用旧 CRM／ERP；旧系统里的某个模块也可以变成以 AI 完成任务为中心的体验。

“加了聊天框”“使用了 Agent 框架”“流程复杂”都不足以单独说明 AI 原生。这里采用的工作定义是：产品的核心任务体验和协作方式围绕 AI 能力重新设计，而不仅是增加一个附属功能。

2. 两条落地路线

路线一：节点增强——流程基本不变，AI 承担部分工作

从现有流程找出需要阅读、归纳、抽取或语义判断的节点，替换或辅助其中的人工操作，保留必要的复核。

以合同审批为教学示例：员工提交合同后，原程序检查必填项与确定性规则；AI 整理风险和引用依据；审核人复核；原审批流程决定后续状态。

适合的任务包括客户沟通摘要、材料信息抽取、审核意见草稿、工单分类建议、报告分析段落生成。这里的示例是设计设想，不是本项目已实现的功能清单。

不必为了接入 AI 就引入 Agent Loop。 一次模型调用能完成的节点，可以只是一个 AI 函数；需要自主选择工具、多轮查证和补充材料时，再使用智能体。

路线二：任务重构——围绕业务目标，重新分配工作

不逐一模仿原来的点击步骤，而是重新定义人交付什么目标、AI 完成哪些工作、程序落实哪些约束，以及哪里需要人工介入。

以 CRM 客户拜访准备为教学示例：

销售提交目标：“帮我准备明天拜访这家客户的材料。”
系统绑定客户、发起人、可用资料范围和任务预算。
Agent 查询历史沟通和订单，识别缺口，按需补充行业研究。
交付带来源的拜访提纲、待确认问题和跟进草稿。
人检查、修改；需要写回 CRM 或发送给客户的动作，经过相应权限与确认机制。

人从“逐步操作”转向“委派、检查产物和处理例外”。原来的客户表、订单表、看板和审批页依然有价值，不需要全都改成聊天界面。

两条路线怎么比较

判断项	节点增强	任务重构
设计起点	现有流程的某一步	用户要完成的业务目标
主要变化	谁执行该节点、怎样产生结果	人、AI、程序的分工与交接
用户体验	原页面增加建议、草稿、审核结果	委派入口、任务进度、产物和待确认事项
AI 自主程度	可以是单次调用，也可以有内部循环	按子任务授予自主空间，不代表完全开放
主要验收问题	节点是否更快、更准，是否增加复核负担	整件任务是否更好完成，总耗时与返工是否下降
两者关系	可以作为重构后流程的一个组件	可以复用已有节点增强能力

复杂度不是分界线。 复杂但规则确定的流程依然适合程序；一个很小的资料查证节点也可能需要自主探索。任务重构也可能主要由固定流程与多个 AI 节点组成，不一定需要开放长循环。

4. 一套业务系统里，谁负责什么

下面是可用于设计的职责划分，不要求每一行都独立建设一个平台或微服务。

职责	建议负责方	不应混淆的边界
客户、合同、订单、正式审批与交易状态	原业务系统及其业务服务	聊天记录或 Agent 的“完成”声明不能替代正式业务记录
理解材料、生成候选结论、选择下一工具	模型与具体 Agent Harness	模型提出动作，不自行决定真实权限
身份、授权、任务调度、运行记录与恢复	现有基础设施加必要的 Company Runtime 能力	已有能力优先复用，不默认再建一套完整企业平台
数据查询与动作执行	受控工具／Tool Broker 与原业务服务	在读取、检索和写入入口落实权限；不能只在前端或 Prompt 限制
材料结构、来源与业务规则检查	Validator 与规则程序	可核验范围需要明确；结构通过不等于事实全对
任务质量、失败类型与改动效果	Evaluator 与人工评测	区分离线评测、在线门禁、Shadow Mode，不把它们混为一体
超出授权或高风险事项	有相应权责的人与组织审批机制	人工确认绑定具体对象、版本与动作；不能一次确认无限复用

具体分层复习 Agent Harness 与企业 Runtime 的边界与企业 Agent Runtime 与 Platform。

“AI 审核”至少拆成三项

内容审查：发现什么问题、依据在哪里、哪里缺证据。
流程决策：找谁、补什么资料、是否升级处理。
正式批准：谁有权使业务对象进入下一状态。

三项可以在同一流程内，但授权和验收需要分开。低风险且规则明确的动作可以按组织政策自动执行；高风险或信息不足时转人工。不能因为输出里出现“审核通过”，就认定已经获得正式批准。

5. “保留原系统”不等于自动无缝接入

身份：区分代表当前用户执行与后台专用 Agent 账号。不要默认给管理员权限；审批、读取与写入权限也不等同。
数据与知识：业务对象、知识来源及其版本应能追溯；知识检索也要执行访问控制，已经读入上下文的敏感内容不能靠隐藏按钮消除风险。
状态：界面需要表达处理中、等待人工、资料不足、失败、完成和结果过期，不能只有一个“启动 AI”按钮。
写回：优先通过原业务服务校验并提交，不让模型任意直写生产表。区分读取、准备变更、正式提交；副作用应有幂等、执行记录与必要的对账。
变更：原合同或规则版本变化后，旧结果可能需要重新检查；重试之前先确认原动作是否已发生。
效果：统计整件任务的质量、总耗时、返工、人工接管和费用。AI 生成快，但人花更多时间纠错，不应算成功。

“任何业务系统都能直接接入”过于绝对。接口、数据质量、授权能力、部署与数据处理约束、供应商许可、改造成本都影响可行性。没有 API 时可以评估受控导出或界面自动化，但这会改变可靠性和维护成本，不能直接当作 API 集成的等价替代。

7. 实际选型时，先填这张任务卡

先回答业务问题，再选框架。此卡是设计检查，不是已批准的实施方案。

要完成的任务与使用者：
当前人工步骤、痛点与已有程序能力：
选择节点增强、任务重构，或两者组合的原因：
输入、业务对象 ID、资料版本与允许访问范围：
哪些步骤是确定性规则，哪些需要模型判断：
AI 可自主执行、需确认、禁止执行的动作：
预期产物、写回位置与完成证据：
失败、超时、重复请求与人工接管方式：
与原流程相比的质量、总工时和成本指标：

实践顺序可从一项边界清晰、能检查结果的任务开始；先验证其价值，再决定是否扩大自主范围或重构更多环节。没有必要为了“AI 原生”标签而扩大工程范围。

9. 从经营报告看任务与业务的两个视角

截至 2026-09-08，经营观察接入案例的项目记录包含真实模型、合成数据与浏览器人工采纳的成功验证，也保留失败记录。这是应用接入闭环，不是对真实经营结论、普遍收益或生产可靠性的证明。

方法主归属仍为智能体系统，公开讲解由大模型与智能体-公司业务系统怎样接入AI 编排。节点增强与任务重构是设计分析框架，不是行业统一标准或先后等级。

业务视角：原来怎样完成报告

以下以同一份经营报告作教学对照，不是对某家公司历史操作的实测记录。原程序提供数据和指标；人查看变化、查找资料、调查原因、写分析，再交有权人员复核和定稿。人既做具体工作，也组织各步交接。

图中三行共用“同一份可复核的分析报告”作为交付目标：第一行是人工组织的基线，第二行只增强草稿节点，第三行重新分配整件任务。逐行展开是为了比较，不表示企业必须依次升级。正式数据和批准责任不会因为切换路线而消失。

业务视角：节点增强

保持什么： 经营观察仍负责数据、指标、报告状态与人工定稿。AI 为“分析草稿”节点提供能力，使用者仍能在原业务页面查看依据、修改与采纳。

改变什么： 人不必从空白处写起。放大草稿节点，内部可以使用 LangGraph、Pi、工具验证和任务运行底座；局部增强并不意味着实现简单。

图的边界： 数据准备 → 指标计算 → 分析草稿 → 人工复核 → 定稿发布，是业务职责的教学抽象。当前验证覆盖草稿和人工采纳，末端表示原系统与组织的责任，不表示 AI 已实现自动发布。

业务视角：任务重构

重新分配什么： 人委派“形成一份可复核的经营分析”，系统绑定范围与资料版本，组织取证和起草；资料不足时转为待确认事项，人集中核实解释、处理例外和决定采纳。正式提交仍经过原业务服务与权限检查。

复用什么： 原数据、指标计算、业务规则、权限与状态服务继续有用。不需要把所有页面变成聊天框，也不需要为了接 AI 将整个业务流程改写为 LangGraph。

图的边界： 这是以同一经营报告任务说明目标委派方式的设计示意，不是对当前应用新增功能的声明。任务内部复用现有架构作为参照，范围绑定、协作和人工交接仍须按具体项目实现和验收。

外部样本：复用业务系统

2026-09-08 仅重新核对以下两份官方资料，不将第三节的全表自动视为最新；本轮未操作这些厂商产品，也未验证采购条件或收益。

Microsoft Business Central：Sales Order Agent FAQ：Agent 在 Business Central 中以独立用户身份和权限执行有限订单任务，原审批工作流可约束变更；文档说明它不负责过账。由此可见，Agent 参与任务与原系统掌握正式业务状态可以并存。
Salesforce：Agent Script Actions：动作定义可以关联 Flow、提示模板或 Apex 等能力。该样本说明可以复用已有业务逻辑，不能据此推断权限、版本和部署已经自动适配。

上述为功能存在性的官方证据，解释是本文的设计归纳，不构成厂商排名、可靠性比较或业务成效证明。

接入架构：从业务入口到原业务服务

2026-09-09 补充职责示意，依据本页第四、五节的分工；不是新增部署或生产验收记录。图中的框表示职责，可合并在已有应用内，不要求每框一个新平台。

业务页面或任务入口绑定使用者、业务对象与目标，展示进度、草稿和待确认事项。入口可以是原页面上的按钮，也可以是独立任务页面。
流程与任务编排负责交接、状态与失败路径。已有工作流优先复用；确有需要时才增加局部编排。它可以调用一个 AI 函数，也可以委派一个 Agent 子任务。
模型与可选 Harness处理语言材料。简单节点只需一次模型调用；需要按反馈选工具、继续查证时，由 Harness 管理循环。LangGraph 可承担局部编排，Pi 可承担探索型子任务，二者不是接入业务系统的必选组合。
受控工具将模型提出的动作转换为有参数与权限校验的业务请求，区分读取、准备变更和正式提交。工具调用原业务服务，而不是让模型任意改生产表。
原业务服务继续提供数据、指标、规则、权限校验与正式状态。图中的请求与返回包含查询结果或提交回执；“生成了草稿”不表示正式提交成功。
人工复核与批准接收草稿、依据和例外，决定修改、退回或采纳；需要批准的提交绑定对象、版本和具体动作，经原业务服务落实。按组织政策已授权的低风险动作可以自动执行，图不要求所有读取都人工确认。
身份与任务运行支撑复用现有认证、调度、记录和恢复能力，必要时补充 Company Runtime。它向编排和执行入口提供身份与运行约束；实际读写仍由工具和业务服务检查权限。

主路径是“入口 → 编排 → AI 工作 → 受控工具 ⇄ 原业务服务”；人工交接是“编排 → 草稿与例外 → 复核／批准 → 原业务服务”。运行支撑对任务和执行入口施加约束。这些箭头表示职责间的交互，不是所有任务都必须按一次直线顺序执行。

最小接入可以只是：原业务页面 → 一次 AI 调用 → 返回可编辑草稿。 跨资料调查、多轮工具选择和任务恢复等需求出现后，再增加相应职责；不要为了画出完整图而一次建齐所有组件。