企业软件的 AI 研发重心：从 Agent 平台转向业务上下文

date

Oct 30, 2026

status

Published

slug

enterprise-ai-harness-business-context

一、三个变化，正在改变平台自研的账本

第一，AI 产品正在争夺任务入口。

腾讯 WorkBuddy 将自然语言请求延伸到任务规划与执行；阿里在 2026 年 8 月公布千问办公公测，强调一站式办公智能体能力；豆包官方资料则将相关能力称为专业版的“办公任务模式”，支持任务拆解以及电脑、文档、表格、网页等工具调用。它们不意味着企业系统已经全面打通，但共同指向了从“回答问题”向“完成任务”的转变。腾讯产品页、阿里发布公告、豆包官方说明。

第二，开源 Harness 提供了复用执行底座的路径。

这里的 Harness，可以理解为围绕模型组织任务执行的运行框架，包括推理与工具调用循环、上下文管理、执行环境等能力。DeepSeek Harness 官方项目提供 Agent Loop、工具调用、Skills 与沙箱相关实现，目前官网标注为公共预览。企业可以据此评估二次开发，但开源框架并不自动等于企业级成品，权限、安全、审计、隔离和运维仍要逐项验证；沙箱能力也受平台与配置影响。官方产品页、Agent Loop 说明、沙箱文档。

第三，运行底座也出现了托管服务选项。

微软在 2026 年 10 月 28 日宣布，Foundry Agent Service 中的 Microsoft Copilot harness 进入公共预览，由微软管理 Agent 循环与沙箱，开发者提供指令、技能、工具等配置。需要区分的是，这仍是公共预览，不能直接当作已经全面正式商用的成熟方案。对于企业研发而言，它至少增加了一个可评估的采购选项。微软 Foundry 公告。

这些变化不能证明自研平台已经没有价值，但它们改变了比较对象。

过去的问题可能是“我们能不能把 Agent 做出来”。现在更应追问：“相同的业务结果，自己做、基于开源开发、采购托管服务，哪种方式的全周期成本更低，控制力又足够？”

二、入口变化之后，业务软件的价值在哪里

统一 AI 入口可能让一部分用户不再先打开 CRM、ERP，再寻找其中的 AI 助手，而是直接提出任务，让 Agent 调用背后的业务系统。

这是一个值得准备的方向，不是业务软件界面必然消失的结论。复杂审批、批量操作、异常处理和专业分析，依然可能需要成熟的业务界面。

但企业软件厂商需要考虑一个新问题：

当用户不从我的页面进入时，我的业务能力还能不能被正确发现、安全调用，并且持续创造价值？

过去，产品能力往往通过菜单和表单被理解。面向 Agent，这些能力还需要被表达为清晰的业务对象、可验证的规则和有边界的操作接口。

如果软件只能通过人工点击完成工作，外部 Agent 就不得不依赖脆弱的界面模拟。相反，一套语义明确、权限可控、结果可追溯的业务接口，能让软件继续参与任务完成，即使任务起点已经移到别处。

当然，开放接口不会自动带来收益。还需要设计租户授权、调用配额、计费、合作关系和客户归属，避免开放了能力，却失去了服务客户的能力。

三、业务上下文，远不止一个知识库

知识库擅长帮助 Agent 找到说明文档。但“读过业务说明”和“能够正确办理业务”，中间还有很长的距离。

以 CRM 为例，让 Agent 完成一次会员召回，至少需要六类上下文。

1. 业务对象与语义。

什么是会员、客户、联系人、订单、权益和营销活动？它们如何关联？“近 90 天未购买”是没有支付订单，还是没有完成订单？退款订单是否计入？

2. 当前状态。

会员等级、可用权益、最近交易、正在参与的活动、是否已退订营销消息，都必须来自当前可信数据。文档里写着“金卡会员享受优惠”，不能替代此刻的会员资格查询。

3. 业务规则。

优惠能否叠加、最低毛利要求、适用品类、活动有效期、区域限制，需要有明确版本和生效条件。关键规则应由业务服务或规则引擎执行，不能只靠模型读 Prompt 后自行遵守。

4. 身份与权限。

谁发起任务？属于哪个租户？能看哪些客户、能批准多少预算？这些约束必须在服务端执行。Agent 判断“可以操作”，不等于系统已经授权。

5. 可执行的业务动作。

“发券”不只是一个接口名称。它需要清楚的输入要求、前置条件、影响范围、幂等机制、失败返回和结果查询方式。必要时还要有撤销或补偿流程。

6. 完成标准与证据。

任务结束不能只以“模型说完成了”为准。哪些会员被选中、规则如何校验、谁批准了操作、实际执行了多少、哪些失败，都应该能被核对。

因此，业务上下文更适合被建设成一套持续维护的业务资产：既有说明，也有实时查询、规则执行、权限约束和结果证据。

它也不意味着把全公司的数据塞进上下文窗口。应当按任务和权限提供最小必要信息，并明确来源、更新时间和失效条件。

四、把 CRM 召回任务拆开，差距就清楚了

假设运营提出：

“找出近 90 天没有购买的高价值会员，制定召回方案，在预算内发放优惠券。”

一个能演示的 Agent，可能查询名单、生成文案，再调用发券工具。

一个能进入生产环境的 Agent，还要回答：

“高价值”使用什么口径？消费金额是否扣除了退款？

哪些会员禁止营销触达？是否存在重复召回或正在进行的活动？

优惠券与现有权益能否叠加？是否影响毛利底线？

预算按发券面额、预计核销成本，还是实际核销金额计算？

多个任务同时执行时，预算会不会被重复占用？

当前操作者有审批权吗？超过阈值该交给谁？

批量发券部分失败后，重试会不会重复发放？

比较稳妥的流程应当是：

明确目标与业务口径，查询当前状态。

生成候选名单与方案，先做规则校验和成本预估。

输出预览，按风险和金额阈值进入审批。

执行前再次检查状态、权限与预算，必要时先做额度预留。

通过幂等业务接口执行，并记录每一项结果。

对失败项重试或补偿，对执行效果进行复核。

这里的预算校验、额度预留和幂等性，应由确定性的业务系统保障；模型负责理解需求、提出方案和协调过程。

Harness 可以帮助推进循环、调用工具、保存任务状态。但“什么操作才算正确”，仍需要业务系统给出答案。

五、自研、开源二开、采购，应该怎样选

不能因为通用能力越来越容易获得，就把所有底座工作都停掉；也不能因为已经投入很多，就默认继续投入是正确的。

适合更多采购或复用的能力，通常具有较强通用性，而且市场方案已经能满足需求。评估时要把模型适配、升级维护、值班、故障处理、合规、迁移和退出成本一起算进去。

适合基于开源增强的情况，往往是企业需要部署控制、特定集成或运行行为定制，同时有能力承担安全修复、版本跟进和运维。开源减少重复开发，不会让长期责任消失。

适合持续自研的部分，应有可验证理由，例如特殊部署约束、严格的延迟与成本要求、现有方案无法满足的执行语义，或者运行平台本身就是公司的核心商品。

采购和开源都不能替企业承担最终业务责任。无论底座来自哪里，企业仍需要保有身份与租户隔离、操作授权、审批、审计、异常处置、质量评测等必要能力。

真正值得削减的是缺少差异化、又没有明显成本优势的重复建设。

六、研发重心转移后，交付物也应该改变

如果还用“接入了多少模型、支持了多少工具、做了多少 Agent”衡量进展，团队很容易继续扩建平台，却难以证明业务改善。

可以先选一个高频、边界明确、结果可验证的场景，交付以下几件东西：

一份业务对象和口径说明，明确由谁维护。

一组只读查询与受控写入接口，写入具备审批、幂等和审计。

一套包含正常、异常、越权、过期规则和并发冲突的测试案例。

一条从请求、决策依据到实际结果的追踪链路。

一份自研、开源和托管方案在同一任务集上的成本与质量比较。

衡量指标也应回到任务本身：有效完成率、错误执行率、人工接管率、平均完成时间，以及每次有效完成的总成本。

其中，总成本应包含人工复核和失败补救，不能只看模型调用费。对营销任务，还要区分“成功发券”和“真正带来增量收益”，后者需要对照实验或其他可靠评估方法。

当这些业务资产可以同时服务于自有 Agent 和经授权的外部 Agent，企业就获得了更大的底座选择空间。模型或 Harness 更换时，也更容易用同一套任务和证据验证是否真的变好。

七、如果明年只有一笔新增预算

如果选择题是：

A. 继续完善自己的 Agent 平台。

B. 企业业务上下文与业务能力开放。

对多数主营 CRM、ERP 等业务软件的公司，我更倾向于 B，同时给 A 保留必要的运行与治理预算。

前提是，现有底座已经达到可用、安全和可维护的基本要求。如果这一层还存在严重缺口，先补齐短板更重要。对于专门销售 Agent 基础设施的企业，A 本身可能就是核心业务，答案自然不同。

还要警惕把 B 做成另一场庞大的“上下文平台建设”。如果长期停留在建模、整理文档和接入数据，却没有任务真正跑通，研发资源只是换了一个地方消耗。

可以从一个业务闭环开始，证明效果，再逐步复用。

Harness 决定 Agent 怎样运行，业务上下文和业务系统共同决定它能否把事情做对。

更强的模型、更完整的运行框架，未必能替企业软件厂商理解会员生命周期、交易语义、审批边界和经营规则。

面向 2027 年，值得重新追问的不是“平台功能还缺多少”，而是：

下一笔研发投入，能否让一个真实业务任务更可靠、更便宜、更容易被验证地完成？

如果你负责企业软件的 AI 研发，明年会把更多新增预算投向哪里？

A. Agent 平台与运行治理能力。

B. 业务上下文与业务能力开放。

欢迎结合企业所处阶段，谈谈你的选择与理由。

本文基于所提供观点整理并拓展。产品信息核对截至 2026 年 10 月 30 日（北京时间）；研发取舍和示例流程为分析建议，不代表各厂商已具备文中全部企业级能力。