我们为什么相信“业务系统＋Agent”是当前AI应用的更优解？

在织信，我们考虑AI怎样参与企业工作时，总要往后多问一句：AI已经给出了处理建议，接下来，这件事由谁继续做？

我们先看一种生产异常处理方式：AI读完一段现场描述，可以归纳异常情况，提示可能的影响，给出处理建议。生产主管看完，觉得分析得有道理。可要让现场照着处理，他还得找到对应工单，确认当前状态，再联系采购、质量或者设备人员。

等相关人员处理完，还要有人把结果补进系统。否则，第二天再问这张工单为什么没完成，AI可能仍在引用昨天那条异常。

建议已经有了，大家却还在搬运信息、分派任务、追问进展。这部分工作如果没有减少，企业很难仅凭一份分析，就判断AI到底带来了多少改善。

因此，我们在考虑织信的AI能力时，会把问题往后多问一步：这次分析之后，业务记录会发生什么变化，下一位负责人能不能据此继续工作？

这也是我们看好“业务系统＋Agent”的原因。对于需要反复查询、判断、处理和跟进的企业工作，两者结合，更有机会把AI的能力用到日常经营里。

这里说的Agent，可以先理解为能根据任务要求、调用系统工具开展工作的AI智能体。它实际能做哪些事，取决于接入的工具、数据和权限。

至于写一封邮件、整理一次会议纪要，单独使用AI工具就很方便，没有必要为了这些任务先建一套系统。我们要讨论的，是另一类事情：有人开始处理以后，企业还需要知道处理到了哪里、结果是否有效，以及出了问题该怎么查。

一、先让AI查一查，问题会具体很多

为了把这件事讲清楚，我们在织信的制造业演示应用里，做了一次只读查询。这里使用的是演示数据，不对应客户实际生产。

问题很普通：按车间汇总生产工单的计划数量、合格数量、待检数量，以及未完成的工单数。

应用内的智能体读取记录后，得到的总计是：计划数量3670，合格数量1120，待检数量1470，未完成工单5张。与列表逐条核对，这几项汇总一致。不同产品的数量合计，在这里仅用于验证汇总功能，不能直接作为产能或交付指标。

这一步的方便之处，业务人员容易理解。我们不必先把数据导出，再告诉AI哪一列是什么，就可以围绕应用中的记录提问、继续追问。

但查到这些数字，能不能直接回答客户还有多少货可以交？

还不能。

1470是待检数量，检验尚未确认，当然不能直接算作可交付。1120虽然记为合格，也还要看对应哪张订单、是否入库、有没有被其他需求占用，以及是否满足本次发货要求。

这里有一个容易被忽略的区别：AI把现有数据查对了，不代表现有数据已经足够回答业务问题。

这次查询还提醒了我们另一件事。智能体最初在解释缺失信息时，认为没有实际完工日期，就无法识别逾期。这个说法需要纠正：对尚未完成的工单，可以先拿计划完工日与当前日期比较，筛查计划逾期；判断客户交付是否受影响，则还需要订单承诺等信息。

你看，接上数据以后，核对反而有了具体对象。哪些数字查得对，哪句话解释过了头，缺的是哪个字段，我们可以回到记录上讨论，不必只凭一段回答听起来是否专业来判断。

织信的AI数据智能体支持自然语言筛选、分组和聚合分析，定位是读取与分析。它适合帮助员工找出需要关注的记录。应用内会话还可按授权使用其他模式，但查询权限不能直接当作执行权限，正式修改数据、安排任务，要走相应的业务操作或执行流程。

二、系统里已经有的东西，AI也需要用上

刚才查的是工单。接下来，我们打开同一个演示应用的生产异常表，让智能体找出尚未处理完的异常，按类型汇总，并列出记录中的处理岗位。

这次查到的未处理完异常共5条：缺料2条、质量待判2条、设备停机1条，记录中的处理岗位分别是计划岗、质量岗和设备岗。

注意，这里统计的是异常记录，前面统计的是工单。一张工单可以对应多条异常，两个数字不能当成同一个指标。

其中就有一条问题描述写着“首件尺寸超差，待质量判定”。AI能帮我们找到这条记录，但谁来判定、如果需要返工又由谁复查、什么条件下允许继续生产，还要看企业的处理要求。查询到这里，验证的是找出异常；后面的分派、复核和写回，还需要配置相应步骤。

企业通常已经有相应要求。质量人员负责判定，生产人员按结论处理，必要时由技术人员确认方案。系统中的异常状态、处理结论和操作权限，就是为了让大家按这套要求协作。

过去做信息化，我们花力气把这些内容整理进系统。到了AI阶段，它们仍然要用，只是多了一种使用方式。

例如，员工说“这批货应该处理好了”，Agent需要知道，他指的是返工结束、复检通过，还是已经具备发货条件。这几个状态，后面接着的动作完全不同。

如果系统只留下一段含糊的备注，AI也很难可靠地区分。把状态定义清楚，把工单、异常和检验记录关联起来，再让Agent查阅，判断才有依据。

所以，在织信，我们把数据模型、流程、权限和系统集成，与AI能力放在一起建设。企业可以用它搭建ERP、MES、CRM、采购和项目管理等应用；已有系统运行得好，也可以通过API、脚本、外部数据源或MCP连接需要的能力。

不必为了用AI，把原来的系统再做一遍。需要先确认的是，订单、库存、检验结果分别由哪里维护，Agent读取哪一份有效记录，更新又应该写回哪里。否则，同一批货多出两套状态，查询方便了，核对却更麻烦。

业务系统给AI提供的，不只是一些数据，还包括这些数据在企业里究竟意味着什么。

三、让AI往下做，为什么还要把动作拆开？

查出问题之后，大家自然会希望：能不能让Agent顺手把后面的事情也处理了？

可以探索，但要先看清它准备做什么。

一条生产异常描述，需要有人读懂，判断属于质量、设备还是物料问题。这部分适合交给AI辅助处理。可如果只是“超过约定时间仍未完成，就提醒负责人”，条件已经很明确，用普通自动化就能做，没有必要每次请模型重新判断。

织信的“调用智能体”自动化步骤，可以把需要理解的内容交给Agent，并按任务选择模型、专家、技能和知识库。结果返回后，后续步骤再进行检查、更新记录、发送通知或推进流程。

启动这项工作，也不必每次都由员工打开聊天框。企业可以通过表单按钮、数据监听器等入口调用配置好的自动化。比如异常提交时先分析分类，负责人确认后再安排处理。前提是配置好触发条件、传入哪些记录，以及实际使用哪个账号执行。

为了看清这种分工，可以看织信官方文档中的客户反馈分诊示例。它与生产异常分类有相似的处理顺序：先理解一段描述，再把结果交给后续业务步骤。下面展示的是这套示例的真实配置界面，并非本次已经运行完成的生产异常流程。

放到生产异常场景，我们建议先这样安排：Agent读取异常描述和相关规范，返回建议类别、判断依据，以及是否需要人工复核。随后检查类别是否在允许范围内、目标工单是否存在，再决定交给哪个岗位。

这里为什么还要多一道检查？

因为一句“建议转质量部门”，交给人看，大家大致能理解；交给系统执行，就必须对应到有效的分类和接收岗位。返回内容少了字段、类别不在选项里，或者没有找到负责岗位，都应该进入待确认处理，不能悄悄当成成功。

织信官方反馈示例中，就用代码片段检查返回的类别和优先级。如果不在预先列出的选项里，这一步会报错，避免继续按错误分类更新。要把失败结果转交人工，还需要另外配置接收岗位和异常处理分支。

遇到返工、报废、放行这类决定，我们更倾向于让Agent整理依据，由有权限的人员确认。判断明确、风险可控的分类和提醒，再逐步交给自动化。

不需要让模型包办每一步。把需要理解的事情交给AI，把已经明确的规则交给系统，双方的长处才用得上。

四、比“执行成功”更值得追问的，是失败以后怎么办

说到这里，还要谈一个不太显眼、却会影响上线的细节。

织信的调用智能体文档特别说明：Agent通过工具修改的数据，可能由独立运行提交。后面的自动化失败，并不意味着前面已经成功的修改一定撤销。

这会带来什么问题？

举个配置风险的例子：Agent先创建了一张处理任务，后面的通知发送失败了。界面显示整次执行失败，管理员重新运行，结果又创建了一张相同任务。负责人最后收到两张单，却不知道该处理哪一张。

这不是多写一句“请不要重复执行”就能放心的事。

因此，对于这类任务，我们建议让Agent先返回分析结果，再由普通自动化步骤校验目标、检查是否已有任务，最后执行写入。通知失败时，也要能分清哪些操作已经完成，哪些需要补做。

上图中的只读模式和结构化输出设置，就是一种实际可用的配置方式：先让AI分析，写入交给明确的后续步骤。这里的结构化输出，就是把判断分成类别、摘要、是否需要复核等固定项目，方便后续步骤逐项检查。

在同一套官方示例里，写回步骤把这些项目分别对应到数据表字段，并按传入的记录ID定位当前反馈。分类写到分类字段，摘要写到摘要字段，判断依据也一并保留。后面的负责人打开原记录，就能继续核对和处理，不必再到聊天里找结论。

权限也要按同样的思路处理。能查询工单，不应顺便获得修改检验结论的权限；能提出调整建议，也不等于可以发布新流程。

织信提供AI能力授权和会话模式，以及应用、记录、字段等业务权限配置。实施时，要把这些限制落实在账号和工具调用上，并用不同角色验证。仅在提示词里写一句“不要越权”，替代不了系统检查。

企业愿意把工作交给AI，需要的不只是一次成功。还得知道：出错时能不能停，已经改了什么，谁可以接手，怎样避免再改一次。

五、流程能调整，企业才有机会把AI越用越合适

到这里，可能有人会问：这些规则都要先定好，那AI应用是不是又变成一个很长的建设项目了？

我们更愿意把工作拆小，但保留从发现到处理结果的完整过程。

例如，先选一种生产异常，让Agent辅助分类，负责人确认后再转交处理。运行一段时间，看看哪些描述总是分错，哪些记录经常缺信息，哪个岗位收到任务后仍要来回追问。

发现问题，再改相应的地方。有时需要补一个“影响工序”字段，有时需要调整分类规则，有时则要增加技术复核节点。无需一开始就把所有异常、所有岗位都交给Agent。

这也是织信低代码能力与AI结合的实际意义。数据表、关联关系、表单、工作流和自动化可以围绕同一项业务调整；智能体对话开发也能辅助生成、修改这些配置。生成之后，仍然要检查规则、测试权限和异常情况，再决定发布。

业务部门提出“这种情况不能直接关单”，我们就需要有办法把这句话变成可执行的状态条件和复核步骤。否则，前面讨论得再细，最后还是要靠负责人记住。

还有一点要说清楚。织信自动化中的“调用智能体”是单轮调用，不会自动带上上一次运行的对话。想让它知道上次怎么处理，就要把处理结论保存为记录，在下一次需要时明确提供，或者检索经过维护的知识资料。

所以，所谓越用越合适，需要有人持续维护数据和规则，也需要检查AI的判断。它不会因为看过几次记录，就自动掌握企业全部经验。

我们建议先看几项朴素的结果：异常提交后多久找到负责岗位，分类结果有多少被人工改正，同类问题有没有重复派单，关闭的异常是否留下了有效处理结论。把这些与启用前按相同口径比较，比只统计AI调用了多少次，更容易看出值不值得继续投入。

写在最后

我们相信“业务系统＋Agent”，因为企业需要的工作结果，通常还要被下一位同事继续使用。

质量人员确认的结论，生产要据此安排返工；返工完成的记录，检验人员要据此复查；问题最终有没有解决，主管还要能查得到。

Agent可以让查找、理解和整理这些信息更方便。业务系统则把确认过的结果保存下来，让相关岗位按照规则继续处理。两者配合得好，员工少做的，才不只是几次复制粘贴，还包括那些反复找人、重新解释和核对状态的工作。

这就是我们希望通过织信交付的价值：员工提出一个问题之后，既能更快得到有依据的回答，也能让确认过的处理办法，在系统里继续执行下去。

AI是否真正进入了业务，不妨就从这里判断。