去年做一个 Agent，很多人熟悉的动作是打开 Coze 2.0 的工作流编辑器，把“接收消息”“解析 JSON”“调用 CRM API”“发送通知”这些节点串起来。
这套方法好用。尤其是任务边界清楚的时候，比如固定格式的营销报告、标准化表单录入、客服话术草稿生成。开发者知道每一步该发生什么，只需要把流程画出来，再把模型放进某几个节点里。
问题出在另一类场景：流程看起来简单，实际全是例外。
电商售后就是典型例子。用户可能说“想退货”，也可能说“东西味道不对，但我不确定是不是我的问题”。前者能走退货流程，后者就麻烦了：它可能是质量投诉，也可能只是咨询；可能需要补照片，也可能要查物流、订单、历史沟通记录。低代码工作流当然可以继续加分支，但分支越多，维护成本越高，最后会变成一张谁也不敢改的流程图。
IBM 在《2026 年 AI 智能体指南》中对 AI Agent 的定义很直接：它是能够设计工作流、利用工具，并代表用户或系统自主执行任务的系统或程序。这个定义里，关键不只是“会聊天”，而是会调用工具、做决策、和外部环境交互。
这也是 Coze 之后，开发方式真正发生变化的地方。
低代码编排还没过时，但边界更清楚了
Coze 2.0 这类平台的价值，并不应该被低估。Agent Skill、Agent Plan、Agent Coding 这些能力，让很多长链路任务第一次有了比较容易上手的结构。对于企业内部的轻量自动化，它依然是很合适的入口。
比如一个固定的 CRM 填单机器人：用户提交线索，模型抽取姓名、公司、需求，再调用接口写入系统。这里的难点不在“智能”，而在稳定。流程越明确，低代码编排越有优势。
但到了售后、风控、跨部门审批这类任务，情况会变。开发者很难提前写完所有分支。你可以预设“退货”“换货”“仅退款”“投诉升级”，但用户表达并不会按菜单来。只要业务里出现大量模糊描述，流程驱动就会开始吃力。
AutoGLM 这类自主智能体工具被讨论，正是因为它瞄准的不是“把节点拖得更顺”，而是让开发者直接描述目标，再由智能体拆任务、选工具、执行和校验。
这不是说开发者可以撒手不管。恰恰相反，开发者的工作从写每一步，变成定义它能做什么、不能做什么、做到哪一步必须停下来等人确认。
售后场景里，难的是“没写进流程”的部分
还是看电商售后。
如果用传统工作流做，开发者大概会设计这些步骤：识别用户意图，读取订单，判断是否在售后期，匹配退货政策，生成回复，必要时转人工。听起来完整，但真实客服对话往往不会这么规整。
用户可能先抱怨，再补充订单号；可能一开始说“不要了”，后面又说“其实能换一个也行”；也可能上传的照片不清楚，需要再次追问。
在更自主的 Agent 设计里，开发者不再把所有动作写死，而是给它一个目标和工具集。例如：处理因质量问题导致的退货，核实订单和物流状态，在不确定时追问用户，不得直接承诺退款，涉及金额操作必须交给人工确认。
这样一来，智能体要做的不是简单执行某条路线，而是根据上下文做几件事：
- 判断用户是在咨询、投诉，还是已经提出明确售后请求；
- 调用订单、物流、客服记录等工具；
- 当信息不足时继续追问，而不是直接报错；
- 生成回复前检查是否越过了业务权限；
- 对关键动作留下记录，方便复盘和审计。
这类变化听上去像产品能力升级，本质上是开发责任的迁移。过去开发者主要负责“把流程搭出来”；现在更重要的是把权限、证据链、人工介入点设计清楚。
数字很热，落地没那么快
关于 AI Agent 的预期已经被拉得很高。知乎专栏《Agent智能体开发模式，第10章2025–2026 前沿全景与选型指南》中转述 Gartner 预测：到 2026 年底，40% 的企业应用将嵌入 AI Agent，而一年前这个比例不足 5%。同一篇文章还提到，近三分之二的组织正在实验 AI Agent，但成功扩展到生产环境的不足四分之一。
这组数字值得看，但更值得看的是中间的落差。
很多团队已经能做出 demo：让 Agent 查资料、写邮件、调接口、生成代码。但进入生产环境后，问题会立刻变具体：它调错接口怎么办？它生成的代码能不能运行？它有没有权限读取这条数据？它是否应该把回复直接发给客户？
ModelEngine 社区文章在盘点 LangChain、Dify、Coze 等框架时提到，智能体通常要把大模型与工具调用、记忆系统、推理规划等能力结合起来。也就是说，Agent 工程不是只接一个模型接口。工具、记忆、规划，每一层都会引入新的不确定性。
所以，2026 年讨论 Agent 开发，重点不该只是“谁更自主”。更现实的问题是：它自主到什么程度，哪一步必须被约束。
AutoGLM 式体验背后，是更重的工程账
如果把 AutoGLM 这类工具理解成“自然语言写需求，智能体自己拆解并执行”，它的吸引力很明显。开发者不用为每个边界情况写死流程，模型可以在运行中根据上下文选择工具，甚至生成一段脚本处理接口返回格式。
但这也带来三笔账。
第一笔是控制账。Agent 如果能调用 API，就必须知道哪些 API 只能读，哪些 API 可以写，哪些操作必须二次确认。售后场景里，“查询物流”和“发起退款”不是同一级别的动作。前者可以自动化，后者通常需要更严格的权限和记录。
第二笔是幻觉账。腾讯云开发者社区关于 2026 年 Agent AI 的文章提到，高频幻觉在严谨商业分析中是不可接受的风险。放到业务系统里，幻觉不只是答错一句话，还可能表现为编造字段、误解规则、调用不存在的接口。模型越能行动，错误的后果越真实。
第三笔是成本账。自主智能体往往需要多轮规划、工具调用、反思和重试。和固定工作流相比，它的 Token 消耗、延迟和监控成本都会更难预测。对于客服、售后这类高频场景，省下的人力不一定马上覆盖新增的推理和工程成本，企业需要算细账。
开发者要少写流程，多写边界
Coze 代表的低代码编排，解决的是“让更多人能搭 Agent”。AutoGLM 代表的自主智能体方向，想解决的是“当流程无法提前写完时，Agent 能不能自己往前走”。
这两件事不是简单替代关系。边界清楚、步骤稳定的任务，继续用 Coze、Dify、LangChain 这类工具做编排很合理；例外多、上下文复杂、需要跨系统决策的任务，才更适合尝试自主智能体。
开发者的新工作也更像三件事：
- 把业务目标讲清楚，而不是只画流程；
- 把工具权限分层，避免 Agent 一上来就拿到高风险操作；
- 把审计、人工确认、错误回滚放进系统设计，而不是上线后再补。
Agent 开发的变化，不在于“拖拽节点”会不会消失。真正的分水岭是：当 AI 已经能规划、调用工具甚至生成代码时，团队有没有能力把它关在合适的边界里。没有这层边界，自主只会变成新的风险源。
