别再让员工在四个系统里手动创建对象了：一个统一入口如何终结效率黑洞

每天早上，你的销售总监打开业务对象列表，一个一个手动录入客户信息；产品经理在对话框里输入“创建新产品”，然后切到另一个页面手动补全字段；数字员工在后台用关键词匹配，创建出来的对象却总是缺胳膊少腿；小程序用户提交了一个自然语言描述，后端却只能返回“类型不存在”的错误。

这不是个别公司的困境，而是几乎所有企业在数字化转型中都会撞上的墙——对象创建入口多、逻辑乱、体验差。四个入口，四套代码，四种行为，每次版本迭代都要改四个地方，运维成本高得吓人，用户体验更是割裂得像是在用四个不同的软件。

但问题真的有这么难解吗？还是说，我们一直在用“头痛医头”的方式，去治一个本该“统一治理”的病？

痛点：对象创建这件事，为什么成了企业的“四不像”

先看一个典型的场景。一家中型制造企业，同时使用业务对象列表、对话框、数字员工、小程序四个入口来创建对象。听起来很全面对吧？但实际上，这四个入口背后是四套完全不同的逻辑：

• 业务对象列表：用户直接选择类型，系统创建，流程简单，但无法处理自然语言描述
• 对话框：用户输入“帮我创建一个供应商”，系统却不知道“供应商”对应哪个ItemType
• 数字员工：后台用关键词匹配，匹配到了就创建，匹配不到就报错，没有智能意图识别
• 小程序：用户提交“创建新零件”，后端简化版处理，缺少查重、序列生成等关键步骤

结果就是：同一个“创建供应商”的需求，在四个入口里可能有四种不同的结果。有的成功了，有的创建了重复数据，有的直接报错。更可怕的是，每当需要新增一个对象类型，四个入口都要分别修改代码，开发团队疲于奔命，业务部门怨声载道。

这不是技术问题，这是架构问题。而架构问题的解决，往往需要一次彻底的“统一”。

解决方案：一个核心，四个入口，统一行为

我们面对的问题其实很简单：如何让四个入口的对象创建行为完全一致，且都经过同一个已验证的核心流程？

答案也很简单：把核心抽出来，让所有入口都走同一条路。

核心：useCapabilityCreate.create() —— 那个“已验证”的基核

在代码层面，我们有一个经过充分验证的核心函数：useCapabilityCreate.create(itemType, description)。这个函数包含了完整的创建流程：

1. Schema解析：根据ItemType获取Schema定义
2. LLM处理：利用大模型从自然语言描述中提取字段值
3. 双库查重：检查是否已存在相同对象，避免重复创建
4. 序列生成：自动生成序号、编码等
5. 预创建：构建完整的对象数据
6. AML构建：生成SCSAI标记语言
7. SCSAI提交：将对象提交到SCSAI系统
8. 关系创建：建立对象间的关联关系
9. 后置规则：执行创建后的业务规则

这个流程覆盖了对象创建的所有关键环节，而且已经在实际业务中验证过。问题在于，四个入口中只有“业务对象列表”完整使用了这个流程，其他三个入口都绕过了它，用了简化版或自定义版。

意图识别层：让系统“听懂”用户的话

四个入口中，除了“业务对象列表”能直接知道ItemType（因为用户已经选择了），其他三个入口都需要从自然语言描述中识别出用户想创建什么类型的对象。

这就是意图识别层要做的事：

• 类型已知：直接使用用户指定的ItemType
• 类型未知：通过detectItemType检测描述中的对象类型
• 类型存在：直接使用
• 类型不存在：调用ObjectModeler动态创建新类型，然后使用

这个机制让系统具备了“自我扩展”的能力。用户说“创建一个新的客户类别”，系统不仅能识别出“客户类别”这个类型，还能在它不存在时自动创建。这不是魔法，这是智能体架构的自然延伸。

统一入口：POST /api/capability/pipeline/identify-and-create

为了让所有入口都能访问这个统一的能力，我们新增了一个API端点：POST /api/capability/pipeline/identify-and-create。

这个端点的逻辑非常简单：

1. 调用identifyIntent识别意图（确定ItemType，必要时创建新类型）
2. 调用useCapabilityCreate.create()执行创建

就这么两步。但这两步背后，是整个统一方案的灵魂。

四个入口的统一改造：小改、大改、不改

业务对象列表：不改

业务对象列表是最简单的入口，因为用户已经明确选择了ItemType。所以它不需要任何修改，直接调用useCapabilityCreate.create(props.itemType, desc)即可。

对话框：小改

对话框的改造最小，只需要在AiCapabilityBar.vue中增加一个itemType="auto"模式。当用户输入自然语言描述时，系统自动识别类型并创建对象。用户完全不需要关心ItemType是什么，系统会帮他们搞定。

数字员工：大改

数字员工是改造最大的入口。之前的实现使用了关键词匹配和简化版的createObject，缺少序列生成、查重、重试等关键步骤。改造后，数字员工将使用完整的identifyIntent流程，并调用与useCapabilityCreate.create()同级逻辑，确保创建质量。

小程序：改后端API调用

小程序的改造集中在后端。之前小程序调用的是简化版的POST /api/unified/create，现在改为调用统一的identify-and-create端点。前端代码几乎不用改，后端逻辑完全统一。

技术实现：不动的和动了的

在这场统一改造中，我们刻意保持了一些核心模块不变：

• useCapabilityCreate.js：基础核心，不碰
• useCreate.js：备选方案，不碰
• AmlBuilder.js：AML构建，不碰
• PromptBuilder.js：Prompt构建，不碰
• unified-create.js：后端简化版，不动

而改动的文件只有三个：

1. object-modeler.js：增加SCSAI ItemType创建能力
2. capability-pipeline.js：添加ObjectModelerModule、ensureItemTypeExists、identifyIntent、identify-and-create端点
3. AiCapabilityBar.vue：增加auto-detect模式

这种“最小改动”策略，保证了系统的稳定性和可维护性。

最终效果：一个描述，四个入口，一种体验

当所有改造完成后，用户在任何入口输入“创建一个供应商叫华为，联系人张三”，系统都会：

1. 识别出“供应商”这个ItemType（如果不存在则自动创建）
2. 从描述中提取字段值（名称=华为，联系人=张三）
3. 检查是否已存在重复数据
4. 生成序列号
5. 创建对象
6. 建立关系
7. 执行后置规则

四个入口，一种行为，一套代码。这就是统一方案的价值。

左帮右臂能做什么

统一对象创建入口只是左帮右臂（BossAgents）智能体能力的一个缩影。我们专注于帮助企业构建智能体驱动的统一架构，让AI不仅是一个聊天机器人，而是真正融入业务流程的“数字员工”。

在对象创建这件事上，我们做到了：

• 统一核心：让所有入口共享同一个已验证的创建流程
• 智能意图识别：让系统“听懂”用户的自然语言描述
• 自动类型扩展：让系统在类型不存在时动态创建
• 最小改动：用最少的代码变更实现最大的价值

但更重要的是，我们证明了智能体架构可以解决企业数字化转型中的“碎片化”问题。无论是对象创建、流程审批、数据查询还是业务分析，左帮右臂都能帮助企业构建统一的智能入口，让AI真正成为业务的“左帮右臂”。

如果你的企业也在为多个系统、多个入口、多套逻辑而头疼，不妨想想：如果有一个统一的智能体，能理解所有入口的需求，执行同一套核心逻辑，那你的运维成本会降低多少？你的用户体验会提升多少？

答案，就在你的下一个“创建”请求里。