# 哪些工作最适合建设 Agent？从 Build、Service 到 Operations

最近沿着 Customer Agent 继续往下研究，我原本想回答的是一个很简单的问题：Coding 之后，哪个领域最有可能成为下一个成熟的 Agent 市场？

研究了一圈以后，我反而觉得这个问题本身有点窄了。

Customer Service 已经出现了比较成熟的产品和生产案例，企业内部的 IT Service 与它本质相似，只是服务对象从外部客户换成了员工。Security Operations 也已经开始大量使用 Agent，但继续往外看，服务器运维、网络、制造设备甚至摄像头监控，其实都有相似的工作结构。

把目前已经开始产生稳定价值的 Agent 放在一起，我看到三种反复出现的工作模式：**Build、Service 和 Operations。**

这不是一套需要严格遵守的分类，真正有意思的是为什么恰好是这些工作先跑了出来。继续往下看会发现，它们背后都有很长时间的行业积累。即使很多具体流程今天的工程化程度并不高，这些工作本身已经具备了非常好的工程化条件：输入相对明确，结果能够观察，工作过程中有可以调用的工具，做得好不好也有比较清楚的评价方法。

LLM 出现以后，过去最难被程序处理的那一部分理解和判断能力被补了进来，于是这些已经存在多年的工作链开始真正具备 Agent 化的可能。

## Build：Coding 为什么最先跑了出来

Coding Agent 是目前最成熟的一类 Agent，这件事已经越来越容易理解。

软件开发本身就是高度工程化的工作。工程师接到需求以后，在已有代码库里完成修改，代码可以编译和运行，测试能够发现大量错误，Diff 可以看出具体改了什么，Review 决定修改是否合适，版本管理又提供了回滚能力。

AI 写代码以前，这套体系已经存在很多年。

LLM 真正补上的，是过去很难通过传统程序完成的一段工作：理解自然语言里的需求，读懂大量已有代码，根据上下文生成修改，再根据测试结果继续调整。

于是 Coding Agent 可以沿着一条已经存在的轨道工作：

> Goal → Understand → Modify → Test → Deliver

模型写错代码并不可怕，因为后面有测试。修改方向不对，可以通过 Review 发现。上线以后出了问题，也有日志和版本管理帮助定位和回退。

这也是为什么我越来越觉得，Coding Agent 的成功并不能简单理解成“LLM 特别会写代码”。**更重要的原因是软件工程已经为 Agent 准备好了完整的工作环境。**

Cadence 的 AuraStack 也很类似。PCB 和先进封装设计本身已经有成熟的数据格式、设计规则、专业工具和仿真体系，AI 可以用新的方式理解设计目标并调用这些能力。真正支撑结果可靠性的，依然是行业多年积累下来的工程体系。

一个领域过去积累得越深，Agent 今天能利用的东西就越多。

## Service：自然语言很复杂，服务流程却已经相当成熟

Customer Service 是第二个非常明显的方向。

客服看起来是一项高度依赖人的工作，因为客户说什么完全不可预测。同一个问题可以有几十种不同表达方式，还会混杂情绪、历史背景和各种例外情况。

但如果从 Workflow 的角度看，客服其实已经被企业建设了很多年。

客户提出请求以后，企业会识别他的身份，读取账户和历史信息，根据知识与业务规则判断应该怎样处理，再调用后台系统完成退款、改地址、查物流或者修改账户。处理不了的问题进入人工升级流程，最后还可以通过 Resolution、CSAT、重复咨询率等指标判断服务效果。

它大致是一条这样的工作链：

> Request → Understand → Context → Policy → Action → Resolution

这里真正长期困扰传统自动化的，恰好是前面几步。

客户不会按照数据库字段说话，他会说：

> “为什么我的钱还没有回来？”

系统却需要理解这句话对应哪一笔交易，退款处于什么状态，适用什么政策，以及下一步应该调用哪个业务系统。

LLM 很擅长补上这部分。

这也是为什么 OpenAI Presence、Fin 以及越来越多 Customer Agent 产品都没有停留在“回答问题”上。真正的目标是让模型进入一项具体服务，获得必要的知识和系统权限，在明确范围内完成动作，再把例外交给人。

企业内部的 IT Service 其实属于同一种模式。

员工说：

> “我的 VPN 连不上。”

背后仍然是识别身份、读取设备状态、查找知识、执行操作并确认是否解决。服务对象从客户换成员工，Workflow 的结构没有发生根本变化。

因此，Customer Service 与 IT Service 未必需要被理解成两个 Agent 市场，它们都属于更大的 **Service Workflow**。

## Operations：工作不是由人提出，而是由事件触发

第三种越来越明显的模式是 Operations。

它和前两类最大的不同，是工作不一定等待一个人发出请求。

服务器延迟突然升高，网络出现大量丢包，某个账户产生异常登录，生产设备振动发生变化，仓库摄像头发现异常活动，这些事情自己就会不断发生。

Operations 的基本工作链大致是：

> Event → Observe → Diagnose → Decide → Act → Verify

Security Operations 是目前比较成熟的例子。

安全系统每天产生大量告警，分析师需要查看日志和身份信息，关联其他设备上的行为，判断一个 Alert 是误报还是真实攻击，再决定是否隔离设备、封禁账号或者继续调查。

过去大量时间花在收集和拼接信息上。现在 Agent 可以读取不同系统的证据，把一次安全事件相关的上下文整理出来，甚至根据已有 Playbook 执行部分调查工作。Google 和 Microsoft 都已经把 Agent 用在真实的告警调查和安全运营中。

继续往外看，这种模式远远不只存在于 Security。

SRE 面对服务器日志和监控指标，Network Operations 面对设备状态和网络告警，制造业面对传感器和设备状态，物流系统面对车辆和货物位置变化。它们的输入形式不同，工作结构却很接近。

一个很容易理解的例子就是监控摄像头。

假设一个园区有几百路摄像头，过去需要保安不断观察屏幕。真正困难的地方未必是某一个画面有多难理解，而是一个人根本不适合长时间同时观察几百路持续不断的视频。

这个场景天然已经具备一条非常清楚的 Workflow。

输入是持续产生的视频流，输出是需要进一步处理的潜在风险。AI 可以先从大量画面中找出异常，例如有人进入限制区域、设备附近出现异常活动或者某个区域发生拥堵，再结合时间、位置和其他摄像头的信息判断发生了什么。

最终是否属于真正的风险，可以继续由人确认。

这样的 Agent 并不需要从第一天开始替代整个安防团队。只要它能够把原来需要人长时间机械观察的几百路视频，压缩成少量真正值得关注的事件，价值就已经非常明确。人工确认的结果又可以继续成为反馈，让系统知道哪些告警有意义，哪些属于误报。

这其实已经具备一套非常好的工程化条件：

> 明确的输入，明确的输出，可以持续评价，也天然拥有反馈和迭代机制。

即使过去的处理方式主要依赖人工，它仍然是一条非常适合 AI 进入的 Workflow。

## 真正重要的共同点，是过去几十年的积累

Build、Service 和 Operations 表面上差别很大。

一个人在写软件，一个人在处理客户问题，另一个人在盯服务器和摄像头。

真正把它们放在一起以后，反而能看到非常相似的基础条件。

首先，**工作都有比较明确的触发。**

Build 从一个目标开始，Service 从一个请求开始，Operations 从一个事件开始。Agent 知道一轮工作什么时候开始，也比较容易判断什么时候应该结束。

其次，**输入和输出已经比较清楚。**

Coding 的输入是需求和已有系统，输出是一组可以运行的修改；客服的输入是客户请求和账户状态，输出是问题得到解决；Operations 的输入是持续产生的系统状态，输出是异常被发现、处理并恢复。

它们当然都有大量复杂情况，但至少可以回答一个最基本的问题：

> 这轮工作做完以后，现实发生了什么变化？

第三，**已经存在大量可以复用的工具。**

Coding 有代码仓库、测试和 CI，Service 有 CRM、知识库和业务系统，Operations 有日志、监控平台、传感器和执行工具。

Agent 不需要重新创造企业的软件世界，只需要学会在正确的时候使用这些工具。

第四，也是我认为最关键的一点，**它们都拥有比较好的评价和反馈条件。**

代码到底能不能跑，可以测试。

客户的问题有没有解决，可以看 Resolution 和后续反馈。

服务器有没有恢复，可以继续观察指标。

摄像头发现的风险是不是真的存在，可以由人确认。

评价结果又可以返回系统，成为下一轮修改的数据。

这正是工程体系能够长期迭代的基础。

所以我现在越来越觉得，我们以前所说的“工程化”，并不仅仅意味着企业已经建立了一套漂亮的 SOP，或者某个系统已经高度自动化。

更重要的是，**这项工作本身是否具备被工程化的条件。**

有明确输入和输出，有持续发生的任务，有工具可以执行，有结果可以评价，也能够根据反馈继续改进。只要这些条件存在，哪怕今天大量步骤仍然依赖人，AI 都有机会逐渐进入其中。

反过来，有些工作看起来非常重要，也非常适合发挥人的智慧，却很难回答结果到底怎样才算正确，也缺少持续反馈。这样的工作当然可以使用 AI，但要建设成能够长期自主运行的 Agent，就困难得多。

## 找 Agent，应该先找这样的 Workflow

这也改变了我现在看 Agent 的方式。

面对一个企业部门，很容易问：

> 能不能做一个 AI 财务？

> 能不能做一个 AI HR？

> 能不能做一个 AI 销售？

但一个岗位通常同时包含很多完全不同的工作。

HR 里，员工咨询休假政策属于 Service；新员工入职触发账号和设备准备，更接近 Operations；如果需要修改某个数字系统或配置，又可能是一种 Build。

所以部门和岗位并不是特别好的 Agent 建设单位。

真正值得寻找的是那些已经存在多年、持续发生，而且有机会关闭回路的 Workflow。

对于企业如此，对于个人其实也一样。

一个人可以观察自己的工作：有没有需要不断 Build 的数字对象，有没有持续收到并处理的 Service Request，有没有值得长期监控的 Operations。

然后再问几个更实际的问题：

> 输入在哪里？

> 一轮工作结束时应该产生什么结果？

> AI 可以调用什么工具？

> 做得好不好如何判断？

> 出错以后谁能发现？

> 人工修改能不能成为下一次的反馈？

如果这些问题已经有比较清楚的答案，Agent 才真正有了可以站进去的位置。

我们当然还会看到新的模式，也许未来真的还能找到第四种特别典型的 Workflow。现在更值得注意的是，Build、Service 和 Operations 已经共同展示了一个规律：

**Agent 最先产生稳定价值的地方，往往不是模型看起来最聪明的地方，而是那些经过多年积累，已经具备良好工程化条件的工作。**

LLM 带来了过去很难获得的理解和判断能力，但真正让这些能力持续产生价值的，依然是它周围那条能够运行、评价和不断改进的 Workflow。