申悦
一个想法不一定对：类似TRAE、WorkBuddy这类产品，起初的定位是CodeAgent。它们在AI Coding领域是很强的IDE工具，因为代码世界天然高度结构化：文件、函数、类型、依赖、测试、Git、CLI、API这些概念，都是机器可理解的。但现在厂商直接复用 Code Agent 的 Harness，把它从代码目录搬到员工桌面，让它去读 Word、Excel、PPT、浏览器，再包装成 WorkAgent，开始All In。而这个迁移，我觉得忽略了一个根本差异：企业业务世界不像代码世界那样已经结构化。如果没有先把客户、订单、合同、流程、制度、权限、状态等业务语义建模，Agent 即使会操作软件，也未必真的懂业务。那么现在这一波 WorkAgent，到底是在把已经验证过的 Coding Agent 能力合理扩展到知识工作，还是在用 Coding Agent 的成功制造一种“办公任务也能直接 Agent 化”的错觉呢？Code Agent 的强大，有一部分其实是吃了软件工程几十年结构化的红利，但是企业业务不是这样。比如一句：“帮我判断这个客户现在是否应该升级为重点客户，并跟进下一步。”如果没有统一建模，WorkAgent无法理解什么是重点客户，也没有判断依据，也不知道怎么“跟进”WorkAgent可以操作浏览器、Office、文件系统、MCP、Skills，它很会干活，但不知道企业为什么要这么干。现在很多所谓的 WorkAgent Demo，实际落地展示的都是写PPT、整理Excel、查资料、写报告、做网页、生成图片、处理文件这类基础工作。之所以集中选择这类场景，是因为这些工作高度贴合 Coding Agent 原本就擅长的工作范式：输入文件→理解任务→操作文件→运行工具→生成Artifact→检查结果的固定流程，本质上都属于Artifact Work（工件型工作）。这类型的Demo不会触及真正的企业核心工作，也就是理解企业当前业务状态→整合多系统数据→依据企业既定规则做出业务判断→主动变更业务状态并承担后续业务责任的完整流程，而这一套具备业务闭环、权责属性的工作，才是真正的Business Process Work（业务流程型工作）。
发布于 河南
分享
评论
赞
未登录
友善发言
评论
加载中
