公司业务系统怎样接入 AI。

“用什么系统”和“怎样工作”是两件事。 利用旧系统还是新建系统，是接入基础；增强原流程的一步，还是重新分配一件任务，是工作方式。它们可以自由组合，并受接口、数据、权限与改造成本约束。

两个问题	可以怎样选择	一个例子
业务数据与正式流程放在哪里？	复用现有系统，或按需要新建	新做一个 Agent 任务页面，仍读取旧 CRM 的客户和订单
人与 AI 怎样分工？	节点增强，或任务重构，也可组合	同一个 CRM 里，既有沟通摘要按钮，也有拜访准备任务

接下来两条路线采用同一个目标：交付一份带依据、可复核的经营分析报告。 原来由人查看指标、调查原因、写分析并送审，原程序提供数据与计算结果。这是教学基线，便于比较，不是某家公司原流程的实测记录。概念来源见 两个维度的解释 ↗。

节点增强，就是保留原流程，由 AI 替人做或辅助其中一项工作。 员工仍组织前后步骤，得到的是某个节点的建议、草稿或检查结果。

在报告页面里，人选好数据与指标，点击“生成分析草稿”，AI 返回带依据的文字，人修改、采纳后继续原来的复核与定稿流程。改变的是“不必从空白开始写”，原来的报告对象、页面和审批仍然有用。

1. 原程序完成数据准备与指标计算。
2. AI 接收选定资料，生成分析草稿；缺少依据的解释列为待确认问题。
3. 人查看来源、修改和采纳，再沿原流程送审。

最小接入可以只是一项 AI 函数。 输入材料已经齐全、一次调用足够时，不必引入 Agent Loop。需要查询多份资料、根据结果继续调查时，这个节点内部也可以包含完整 Agent。因此，局部增强不等于技术简单。

经营观察案例已有真实模型、合成数据和浏览器人工采纳的验证记录，覆盖的是草稿与采纳闭环，不能据此声称真实公司报告已能自动发布。具体范围见 节点增强的能力与证据边界 ↗。

节点增强让 AI 帮忙做某一步；任务重构则从整件事的目标出发，重新分配人、AI 和程序的工作。 比如从“请根据这些数据写一段话”变为“请调查本月利润变化，形成一份可以复核的分析”。

人先给出范围和要求；系统组织取数、查证与起草，人集中检查依据、处理例外和决定采纳。原系统继续负责指标口径、业务规则和正式状态。这里是同一经营报告的设计对照，不是当前应用新增功能已上线的声明。

交接	谁做什么	交付给下一步什么
委派	人提出分析目标；系统绑定期间、对象、资料版本与权限	一项范围明确的任务
执行	程序计算指标；AI 整理材料，需要时通过工具查证	带来源的草稿、已完成事项和证据缺口
处理例外	人判断口径冲突、资料不足或无法证实的解释	补充资料、修改意见，或终止决定
采纳与提交	有权人员确认；原业务服务检查并提交	正式记录与提交结果

下面逐行比较同一份报告：原来怎样做、只增强草稿节点、重新分配整件任务。三行是工作方式对照，不是必须依次升级的路线。任务内部的技术实现留在 经营报告架构 中展开。

原流程总体有效，痛点集中在阅读、抽取或写作的一步，可以先做节点增强。痛点横跨多个步骤，员工大量时间花在找材料、来回切换与交接上，可以评估任务重构；前提是范围能约束、产物能检查、失败能接管。

判断项	节点增强	任务重构
设计起点	原流程中哪一步费力？	用户最终要完成什么？
人主要做什么	组织步骤，检查某个节点的结果	委派目标，验收产物，处理例外
AI 能交付什么	摘要、抽取结果、建议、草稿	组合资料与行动，交付整项任务约定的产物
页面怎样变	原页面增加按钮、建议或可编辑结果	增加任务入口、进度、产物和待确认事项
是否需要 Agent	单次调用可以够用，局部也可以有循环	固定编排可以够用，需要探索时再用循环
怎样验收	节点更快、更准，复核负担可接受	整件任务质量、总工时与返工得到改善

两者可以组合：一个拜访准备任务可以复用已经做好的客户摘要、订单查询与提纲生成能力。复杂度不是分界线，也不是任务重构一定更好。 复杂但规则明确的步骤仍适合程序。

换两个场景检验理解：合同审批先增加风险意见草稿，属于节点增强；销售委派“准备明天的客户拜访”，系统组织查询沟通、订单与资料，交付提纲和待确认问题，属于任务重构的设计示例。两者都不表示我们已经上线这些功能。完整定义见 两条路线的比较 ↗。

工作分配清楚后，再决定技术怎样搭。最小接入：原业务页面 → 一次 AI 调用 → 返回可编辑草稿。 当任务需要多轮调查、工具访问和运行恢复时，再增加对应职责。下面的完整图用于定位职责，不是每个项目的采购或建设清单。

位置	通俗解释与职责	可以复用什么
业务页面／任务入口	员工发起工作、看进度、检查结果的地方	原报告页、CRM 页面或独立任务页
流程与任务编排	安排步骤、交接与失败处理	已有工作流；必要时增加 LangGraph 等局部编排
模型与可选 Harness	模型处理语言；Harness 在需要时管理选工具、读反馈、继续执行的循环	简单 AI 函数，或 Pi 等任务执行器
受控工具	把“想查什么、想改什么”变成受权限约束的业务请求	已有查询与业务 API
原业务服务	计算指标、执行规则，保存正式业务状态	原系统的业务逻辑、数据与权限检查
人工复核与批准	判断证据与例外，按权责采纳或退回	现有审批与业务责任人
身份与任务运行支撑	识别执行者，记录、调度和恢复任务	已有认证和运行设施，必要时补充 Company Runtime

因此，LangGraph、Pi 和 Company Runtime 各有位置，但并不是接入 AI 必须集齐的三个产品。原系统已有成熟工作流，就没有必要为了接 AI 全部重写。

图中的交互和最小接入说明来自 接入架构的职责解释 ↗。下一篇 公司知识与系统 ↗ 继续讲这些任务怎样取得知识、关系、事实与工具。

先选一项边界清楚、结果能检查的工作，把下面的空白填好，再讨论框架和模型。先验证价值，再决定扩大自主范围或重构更多环节。

要填的内容	经营报告的教学示例
谁要完成什么，现在哪里费力？	分析人员交付月度报告，查资料和起草耗时
选择哪条路线，为什么？	先增强分析草稿节点，验证质量与复核负担
输入与范围是什么？	指定期间、业务对象、指标口径、资料版本和可访问范围
程序、AI、人各做什么？	程序计算；AI 起草并标注来源；人复核和采纳
可以做、需确认、禁止做什么？	授权范围内查询；采纳需确认；禁止擅自发布
交付什么，失败怎么办？	草稿、依据与缺口；资料不足时退回补充，提交结果不明时先核对再重试
如何与原流程比较？	同等任务范围下比较质量、总工时、返工、人工接管和费用

生成快不等于工作完成得快。例如原来一小时完成报告，AI 两分钟生成、人却花七十分钟核对与重写，就不能仅凭生成速度说效率提高。数字只是评价方法示意，不是项目收益数据。详细设计检查见 完整任务卡 ↗。

旧系统没有可用接口、权限不清或资料不可靠，都会增加接入成本。复用旧系统不等于零改造；没有 API 时的界面自动化也不能当作同样可靠、同样好维护的替代。

会后阅读：外部产品如何复用原系统

微软 Business Central 与 Salesforce 的两个样本及其来源日期，见 官方样本说明 ↗。保留2026-09-08的核验语境；它们说明接入路径存在，不证明某家公司采用后一定有效。