Agent 不只是写代码：非 Coding 领域里的工作流机会

讨论 Agent 时，很多人会先想到 coding agent：读代码、改代码、跑测试、开 PR。这很自然，因为软件工程本来就有清晰的文件系统、版本历史、任务边界和验证方式。

但我越来越觉得，Agent 更大的空间可能在非 Coding 场景里。

不是因为非 Coding 工作更简单，而是因为大量知识工作本来就被拆成了很多重复的任务层：查资料、整理信息、生成报告、做表格、准备会议、跟进客户、检查风险、同步状态、推动审批。它们不一定需要完整自动化，但很适合被 Agent 接管一部分。

最近的几个信号

OpenAI 在 2026 年 4 月 22 日发布了 workspace agents in ChatGPT。这个方向很明确：团队可以创建共享 Agent，让它们在组织权限和控制下处理复杂任务和长周期工作流。OpenAI 给出的例子包括产品反馈路由、每周指标报告、销售线索跟进、第三方风险管理等。

6 月 2 日，OpenAI 又发布了 Codex is becoming a productivity tool for everyone。这份报告提到 Codex 已经不只是 coding tool，知识工作者开始用它创建报告、表格、演示文稿、合同，也会用它做研究、数据分析、工作流自动化和轻量工具。

Anthropic 的产品方向也类似。2026 年 5 月 5 日，Anthropic 发布了 Agents for financial services，提供面向金融服务的 ready-to-run agent templates，覆盖 pitchbook、KYC 文件筛查、月结、财务模型、估值审查、财报一致性检查等场景。重点不是让 Claude “聊天更聪明”，而是把 skills、connectors 和 subagents 打包成可执行的行业工作流。

Anthropic 的 Economic Index 也给了一个更宏观的视角：AI 对复杂任务的加速更明显，而且他们开始用任务复杂度、技能水平、用途、AI 自主性和成功率这样的指标观察 AI 如何改变工作。

这些信号放在一起看，Agent 的重点正在从“模型能不能回答”转向“它能不能在真实工作里推进一个闭环”。

非 Coding Agent 的核心不是自动化，而是承接任务层

我不太喜欢把 Agent 简单理解成“自动帮我做完一切”。这个期待太高，也容易让人失望。

更实际的理解是：Agent 接管岗位里的某些任务层。

比如销售不是被一个 Agent 替代，而是其中的线索研究、CRM 更新、邮件草稿、会议前 brief 可以被 Agent 接管。财务分析师不是被替代，而是其中的底稿整理、口径检查、可比公司筛选、月结清单跟进可以被 Agent 接管。产品经理也不是被替代，而是用户反馈聚类、竞品监控、PRD 初稿、会议结论同步可以被 Agent 接管。

这里的关键变化是，工作从“人手工完成每一步”变成“人定义目标、检查中间结果、批准关键动作”。

为什么非 Coding 更难

非 Coding Agent 的难点也很明显。

第一，数据更乱。代码仓库至少有文件、commit、CI、测试和 review。现实业务数据可能散在 Slack、邮件、CRM、Excel、Notion、会议纪要、合同和人的脑子里。

第二，正确性更难定义。代码可以跑测试，表格可以校验公式，但“这份客户跟进是否合适”“这份风险判断是否站得住”“这个会议总结是否漏掉微妙语境”，往往需要行业经验和组织上下文。

第三，权限和责任更敏感。一个 coding agent 改错代码，通常还有测试、review 和回滚。一个非 Coding Agent 如果发错邮件、误判客户等级、错误处理供应商风险，影响可能更隐蔽。

所以非 Coding Agent 不能只靠模型能力。它需要连接器、权限控制、审批流程、可追踪记录、可回放的上下文，以及人类明确的最终责任。

我更看好的使用方式

我更看好三类非 Coding Agent：

1. 报告型 Agent：定期抓取数据、生成图表、写出摘要、列出异常和待确认项。
2. 路由型 Agent：把 Slack、邮件、工单、用户反馈里的信息归类、去重、分派给正确的人。
3. 准备型 Agent：为会议、客户、项目、投资标的、风险审查准备材料和问题清单。

这些 Agent 有一个共同点：它们不需要一上来就拥有最终决策权。它们先把信息收拢、整理、解释和推进，让人从“找材料”回到“做判断”。

这也是我觉得非 Coding Agent 会先落地的地方。不是把人拿掉，而是把人的注意力从低价值搬运里释放出来。

对工程师的启发

哪怕我们主要做 Android、前端、后端或系统工程，也应该关注非 Coding Agent。

因为软件最终服务的不是代码仓库，而是业务流程。未来很多产品需求会变成：把某个团队的日常流程抽象成 Agent，把组织知识接进去，把权限和审批设计好，把输出变成可检查、可修改、可追踪的工作产物。

这要求工程师不仅理解 API 和模型，还要理解工作流、组织权限、数据质量、可观测性和人机协作边界。

从这个角度看，Agent 的下一阶段不是“会不会写代码”，而是“能不能进入真实工作的摩擦地带”。谁能把混乱的上下文整理成可靠的执行路径，谁就能创造真正的价值。