同样是一项企业任务有的团队会把步骤全部写进工作流只让模型完成分类和内容生成有的团队则希望AI自己判断下一步、选择工具、处理异常直到把任务做完。两种方案都可以叫Agent但风险完全不同。如果流程本来就很稳定却为了显得“智能”而让模型自主规划结果往往不是更高效而是多出一条难以解释的决策链。反过来如果任务必须边查边判断却强行写成固定流程工作流很快会被大量分支和例外压垮。企业做Agent第一步不是选平台也不是先接更多工具而是回答一个更基础的问题这项任务究竟应该给模型多大的自由会聊天与会完成任务是两件事聊天机器人主要交付信息。用户提问模型生成一段回答任务通常在文本输出时结束。Agent交付的是一个过程。它可能需要读取文件、查询系统、调用接口、执行代码、检查结果再决定下一步。它不只“说”还可能对外部系统产生影响。这意味着两者的管理重点不同。聊天机器人的主要风险是答案错误Agent除了可能答错还可能选错工具、传错参数、重复执行、越权访问甚至在错误方向上持续消耗资源。因此Agent不是给聊天机器人加几个工具就完成了。只要AI开始行动企业就必须同时设计权限、反馈、校验和停止条件。判断任务是否需要Agent的4个信号并不是所有复杂任务都需要Agent。可以先看四个信号。信号一需要执行动作而不只是回答问题“今年的差旅标准是多少”通常是一次知识问答。“根据差旅标准检查本月报销单把异常单据标出来并通知对应审核人”则包含读取规则、处理数据、生成判断和触发后续动作。任务的终点不再是一段文字而是业务状态发生变化。只有当任务需要从“知道”走向“做到”Agent才开始体现价值。信号二需要跨系统协同而不是一次调用很多企业任务无法在一次模型调用里完成。它可能先查制度再读表格然后访问业务系统最后把结果写回工单。如果所需信息分散在不同文件和系统中且它们之间存在明确的处理顺序Agent可以承担协调者的角色。但“接入很多工具”不是价值本身。工具越多权限面、失败点和排查成本也越大。只有真正参与任务闭环的工具才值得接入。信号三需要根据反馈调整下一步固定流程可以提前写清楚“第一步做什么、第二步做什么”。Agent更擅长的是路径无法完全预设的任务。例如排查一个系统异常先看监控如果网络正常就检查服务日志如果某个接口延迟异常再继续检查依赖服务。每一步得到的新证据都会改变下一步。这种“根据反馈再决定行动”的任务才需要更强的自主规划能力。信号四结果和停止条件可以验证这是最容易被忽视的一项。如果团队只能说“让AI帮我分析一下”却说不清什么叫完成、什么证据算充分、什么情况必须转人工那么Agent越自主风险越大。真正适合Agent的任务应该能定义至少一种停止状态目标已经达到、证据不足无法继续、达到资源上限或者风险超过阈值需要人工接管。Workflow还是ReAct看任务路径能否提前确定确定任务需要Agent后下一步不是直接追求“自主”而是选择自主程度。Workflow Agent把主要步骤预先设计好。模型可以在某些节点理解文本、提取字段或生成内容但流程方向由设计者控制。它适合审批流、标准化报告、信息录入、固定规则核验等场景。优点是可控、容易测试、容易定位错误代价是面对新情况时不够灵活流程分支多了以后维护成本会迅速上升。ReAct Agent采用“推理—行动—反馈”的循环。模型先判断需要什么信息再选择工具执行根据返回结果继续判断直到任务完成或触发停止条件。它适合调查、诊断、开放式信息查找等路径不确定的任务。优点是能适应变化代价是行为更难预测调用成本和执行时间也更不稳定。所以选择标准不是哪种架构听起来更先进而是任务步骤到底能不能提前写清楚。能写清楚就尽量用工作流只有确实需要根据反馈改变路径的部分才交给ReAct。很多企业应用最终会采用混合结构外层是固定工作流内部少数节点允许Agent自主探索。一个跨文件任务Agent究竟做了什么假设企业有三份资料供应商名单、销售明细以及一份写着月度考核标准的制度文件。现在要找出9月份销售额不达标的供应商。如果让人处理通常会先确认有哪些文件再找到考核阈值检查销售数据结构计算每家供应商的销售额最后与阈值比较。ReAct Agent也可以把任务拆成类似的执行链列出当前可用文件从制度文件中读取9月份达标标准检查供应商信息表的字段检查销售明细的日期、单价、数量和供应商字段筛选9月份数据并计算各供应商销售额与达标标准比较找出异常对象确认证据齐全后结束任务。在这个案例中Agent先从制度文件得到3万元的标准再对表格进行计算最终识别出一家销售额为18,320元的供应商。这里真正值得关注的不是模型“推理了七轮”而是每一轮都有明确目的、工具输入和可检查的反馈。Agent的价值不是把步骤藏起来而是把原本需要人来回切换文件和工具的过程组织起来。自主不等于放手四道边界必须先画出来企业最危险的做法是给Agent开放一组系统权限再用一句宽泛的目标让它自行探索。至少需要提前设置四道边界。第一道是权限边界。读取与写入应该分开授权删除、付款、对外发送、修改核心数据等高风险动作需要人工确认或双重校验。第二道是证据边界。Agent给出结论时应保留使用了哪些文件、调用了什么工具、依据了哪些数据。无法追溯的“正确答案”在企业里仍然难以验收。第三道是资源边界。需要限制最大轮次、执行时间、调用成本和重试次数避免Agent因为找不到答案而无限循环。第四道是停止边界。完成、无解、失败和转人工必须是不同状态。不能把“没有更多办法”包装成“任务已经完成”。Agent平台的难点不只是把模型和工具连起来演示一个Agent接入几个文件和API就能开始。企业要长期运行一组Agent还需要更厚的基础设施。首先是连接器。数据可能存在文档库、网盘、CRM、工单、代码仓库和内部数据库中。每个连接器都要处理认证、字段变化、同步频率和失败重试。其次是数据关系。Agent不只要知道“这份文件写了什么”还要理解内容、人员、部门、权限和业务活动之间的关系。同一份文档对不同角色可能有不同的可见范围。再次是运行治理。一次任务经过了哪些步骤、调用了哪些工具、消耗了多少资源、在哪一步失败都应该能够记录和回放。否则出现问题时团队只能看到最终答案却不知道错误从哪里开始。因此Agent平台的核心能力不是提供一个看起来聪明的对话框而是让多个Agent能够在统一的数据、权限、日志和评测体系下运行。上线前先用这张清单检查在决定把一项任务交给Agent之前可以逐项确认任务最终要改变什么业务状态所需数据和工具是否已经明确哪些步骤可以固定哪些步骤必须动态判断每个工具允许读什么、写什么高风险动作是否需要人工审批正确结果依赖哪些证据怎样判断任务完成、失败或需要转人工最大执行轮次、时间和成本是多少全过程是否能够记录、回放和评测如果这些问题还没有答案企业缺的通常不是更强的Agent平台而是更清晰的任务设计。KD判断Agent的成熟度不看它能自主做多少事而看企业能否清楚控制它何时行动、依据什么行动以及何时必须停下来。Agent不是聊天机器人的升级皮肤也不是可以替业务“保证结果”的数字员工。它更像一套带有智能判断能力的执行系统。把固定的部分写进流程把不确定的部分交给模型把高风险的部分留给人才是企业分配Agent自主权的基本原则。—KD聊企业AI应用不追技术热词只讨论价值、边界与落地。