本文永久链接 – https://tonybai.com/2025/07/15/the-agentic-software-engineer

大家好，我是Tony Bai。

最近，如果你和身边的程序员朋友聊天，很可能会感受到一丝寒意。是的，软件工程行业正在经历一个自 2008 年以来最冷的冬天。职位空缺大幅减少，大厂裁员的新闻不绝于耳。

很多人将矛头指向了 AI：“是 AI 抢了我们的饭碗！”

然而，一篇来自 DoltHub 的深刻文章《The Agentic Software Engineer》提出了一个更本质的观点：别怪 AI，杀死软件工程师黄金时代的，是互联网的普及。

过去 25 年，从互联网到移动互联网的浪潮，创造了海量的工程需求，软件工程师也因此成为了时代的宠儿。但现在，这波巨大的增长红利期已经结束。

那下一个浪潮是什么？文章给出了答案：Agentic AI (智能体 AI)。

这不仅仅是一个新技术，它将彻底重塑我们的工作方式，重写“软件工程师”这个岗位的核心要求。这不是一次普通的更新，这是一场彻底的进化。

告别“代码工人”，拥抱“智能体工程师”

文章预言，软件工程师不会被淘汰，而是将进化，去“驾驭”这波新的 AI 浪潮。我们将成为所谓的 “智能体软件工程师” (Agentic Software Engineer)。

在这个新角色下，我们的工作不再是整天埋头编写成千上万行代码。AI Agent 可以比我们更快、更不知疲倦地完成这项任务。我们的核心职责，将转变为：

一个指挥、协调、审查和运维 AI Agent 军团的专家。

我们从亲自下场比赛的“运动员”，变成了运筹帷幄的“教练”。

AI 时代的生存指南：你的技能升级清单

那么，要成为一名合格的“智能体软件工程师”，我们需要点亮哪些新的技能树？文章为我们梳理了一份极其宝贵的“技能升值/贬值清单”。

技能升值 (Skills++)：这 6 项能力将是你未来的护城河

• 版本控制 (Version Control)

Git 不再仅仅是你个人的代码管理工具，它将成为协调你与成百上千个“AI 码农”协同工作的核心骨干。你需要用它来管理 Agent 的并行工作流、审查 Agent 提交的 PR、以及在 Agent 犯错时进行回滚。精通 Git 模型，将是从业基础。

• 产品思维 (“Product”)

AI Agent 擅长执行，但前提是指令必须清晰。任务分解、需求定义、接口设计等产品经理的核心技能，将成为每个工程师的必备能力。如果你无法将一个模糊的想法拆解成 Agent 可以处理的、足够小的任务块，你将无法与 Agent 高效协作。

• 代码审查 (Code Review)

这是未来我们耗时最多的日常工作。当 Agent 可以在 10 分钟内生成 500 行复杂的代码时，你的价值就体现在审查这些代码的正确性、可维护性和安全性上。接受吧，你正在从一个 Code Writer 变成一个 Code Editor。

• 测试 (Testing)

文章说：“We’re all SDETs now.”（我们现在都是软件测试开发工程师了）。面对一个可能会“创造性”地修改代码以绕过测试的 Agent，编写精准、全面的测试用例，是约束和指导 Agent 行为的最有力工具。 那些热衷于寻找边界条件、享受“破坏”代码乐趣的工程师，将在新时代中变得极其宝贵。

• 系统设计 (System Design)

未来的系统设计，需要更多地考虑如何容纳和管理不那么可靠的 Agent。你需要设计出具有清晰边界、强健接口、高度可测试性的系统，这样即使 Agent 的某个部分出错，也不会导致整个系统崩溃。

• 运维 (Operations)

我们都将成为 “智能体可靠性工程师” (Agent Reliability Engineer)。你需要设计、部署、监控和调试由无数 Agent 组成的复杂网络。当仪表盘上警报响起时，你需要快速定位问题是出在哪个 Agent 的行为上。学习大规模系统的运维之道，宜早不宜迟。

技能贬值 (Skills–)：这些技能正在被 AI 替代

• LeetCode 式算法题： AI 已经能在瞬间解决大部分算法题。
• 语言语法熟练度： Agent 知道所有语法细节，你只需能读懂代码即可。
• 打字速度： AI “思考”和“打字”的速度，是人类无法企及的。

现在，立即开始行动

这篇文章给我们的不应是焦虑，而是行动的路线图。我们应该如何开始？

1. 亲自使用 Agent： 去尝试 Claude Code、Gemini CLI 等领先的编码智能体。找一个终端窗口，看着它工作 15 分钟，感受一下未来的工作形态。
2. “外包”你的日常工作： 在你现有的开发流程中，寻找那些可以“委托”给 Agent 的任务。比如：“为我刚才的提交补充单元测试”，或者“重构这个函数，让它更具可读性”。
3. 刻意练习新技能： 将你的学习时间，有意识地投入到上述 6 项“升值技能”上。

小结：浪潮已至，要么驾驭，要么被吞没

软件工程师的“25年黄金时代”或许已经落幕，但这不意味着职业的终结。

一个由 AI 驱动的、充满无限可能的新时代正在开启。这场变革是不可避免的，拥抱 Agent 的公司，必将“碾压”那些固步自封的公司。而能够驾驭 Agent 的工程师，也必将成为这些公司的核心。

角色的转变或许是痛苦的，甚至会像文章所说的那样，变得有些“无聊”。我们可能会失去一些亲手创造的“流心”时刻。但这是进化的代价，也是我们保持价值的唯一途径。

现在，拿起你的冲浪板，开始学习如何驾驭这波巨浪吧。

成为一名“智能体软件工程师”，从今天开始。

资料链接：https://www.dolthub.com/blog/2025-07-02-the-agentic-software-engineer

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/05/26/monitor-design-with-red

大家好，我是Tony Bai。

随着业务的快速发展，越来越多的应用开始拥抱云原生。我们享受着微服务带来的解耦、容器带来的标准化、Kubernetes带来的弹性伸缩。但与此同时，一个灵魂拷问也摆在了每一位开发者和运维工程师面前：我的服务还好吗？用户用得爽吗？出问题了能快速定位吗？

传统的只盯着CPU、内存、磁盘的监控方式，在高度动态和分布式的云原生环境下，常常显得力不从心，就像“瞎子摸象”，难以窥得全貌。我们需要一种更直接、更面向用户体验、更标准化的方法来衡量服务的健康状况。

今天，我就结合一个通用的示例和大家说一套被业界广泛认可的服务监控黄金法则——RED方法，谈谈如何按照RED方法设计出简单又好用的监控指标与告警。

什么是RED方法？

RED方法并非什么高深莫测的理论，它非常简洁，由三个核心指标的首字母组成：

• R – Rate (请求速率)
• E – Errors (错误率)
• D – Duration (响应时长)

这“三板斧”虽然简单，却直击服务质量的核心。它是由Grafana Labs的VP Product，同时也是Prometheus和OpenMetrics早期贡献者Tom Wilkie于2018年提出的，旨在为现代服务（尤其是微服务）提供一套简单、一致且以服务为中心的监控指标集。

让我们逐一拆解：

R – Rate (请求速率)

• 它是什么？ 指服务在单位时间内（通常是每秒）处理的请求数量，我们常说的QPS (Queries Per Second) 或RPS (Requests Per Second) 就是它。
• 为何重要？ 它是服务负载的直接体现。请求速率的异常波动（骤增或骤降）往往预示着潜在的问题，比如突发流量、上游故障、甚至是恶意攻击。同时，它也是容量规划和弹性伸缩策略的重要依据。
• 关注什么？ 我们不仅要看服务的总请求速率，还应该关注：
  • 按API端点/服务接口划分的速率： 了解哪些接口最繁忙，哪些接口流量异常。
  • 按客户端类型划分的速率： 识别不同调用方的行为模式。

E – Errors (错误率)

• 它是什么？ 指服务在处理请求时，发生错误的请求所占的百分比，或者单位时间内的错误请求总数。在HTTP服务中，我们通常重点关注服务器端错误，即HTTP状态码为5xx的请求。
• 为何重要？ 错误率是服务可靠性的“晴雨表”，直接关系到用户体验。没有人喜欢看到“服务器开小差了”的提示。持续的高错误率是P0级故障的典型特征。
• 关注什么？
  • 整体服务错误率： 快速判断服务是否处于“亚健康”或故障状态。
  • 按API端点/服务接口划分的错误率： 精准定位是哪个功能出了问题。
  • 按错误类型/状态码划分的错误率： 帮助我们理解错误的性质，是代码bug、依赖问题还是配置错误。

D – Duration (响应时长/延迟)

• 它是什么？ 指服务处理单个请求所需的时间，也就是我们常说的“延迟”。
• 为何重要？ “天下武功，唯快不破。” 响应时长是用户体验的生命线。没有人愿意为一个需要加载半天的页面或应用买单。
• 关注什么？ 平均延迟很容易被少数极端慢请求“平均掉”，因此我们更关注延迟的百分位数 (Percentiles)，特别是：
  • P99 (99th percentile): 99%的请求都比这个值快。代表了体验最差的那1%用户的感受。
  • P95 (95th percentile): 95%的请求都比这个值快。
  • P50 (50th percentile / Median): 中位数延迟，代表了典型用户的体验。
  • 同时，也应关注不同API端点/服务接口的延迟分布。

RED方法 vs. 其他监控方法论

你可能会问，业界还有USE方法、Google SRE的“四个黄金信号”等，RED方法和它们是什么关系呢？

• USE方法 (Utilization, Saturation, Errors): 由性能大神Brendan Gregg提出，它更侧重于分析单个系统资源的健康状况，比如CPU使用率、内存饱和度、磁盘错误等。它是RED方法的重要补充，当RED指标显示服务异常时，USE指标能帮助我们判断是不是资源瓶颈导致的。
• 四个黄金信号 (Latency, Traffic, Errors, Saturation): Google SRE实践的精华。RED方法可以看作是对前三个信号（延迟、流量、错误）的一种更聚焦、更易于落地的诠释。RED中的Rate对应Traffic，Duration对应Latency，Errors对应Errors。RED巧妙地避开了相对抽象和难以标准化的Saturation（饱和度），使其更具普适性。

简单来说，RED方法是在前人智慧的基础上，针对现代分布式服务架构，提炼出的一套“最小完备”且“以用户为中心”的服务健康度量标准。

云原生时代，为什么RED如此重要？

微服务架构中，RED方法（Rate、Errors、Duration）为每个微服务提供了独立的监控手段，使得在故障发生时能够迅速定位问题服务。这种方法能够通过服务之间的调用链，清晰地衡量每一跳的性能，从而构建出完整的端到端视图。

在动态环境中，容器和实例的频繁创建与销毁，以及弹性伸缩的特性，使得传统基于单机资源的监控变得复杂。然而，服务级的RED指标能够稳定地反映服务的整体健康状况，无论其背后有多少实例在支撑。

此外，RED指标直接关系到用户体验。Rate、Errors和Duration三个指标分别反映了用户能否正常快速地使用服务。因此，这些指标对于提升用户满意度至关重要。

RED方法还提供了一套标准化的监控语言，适用于不同类型的服务，如HTTP API、gRPC服务和消息队列处理等。这种通用的监控词汇有助于团队的协作与知识传递。

最后，基于RED指标设置的告警能够更精准地反映真实的用户影响，降低误报率，使告警变得更加可操作。这种精准的监控和告警机制不仅提升了服务的可靠性，也增强了团队对服务健康状况的把控能力。

RED简单又强大，那么我们如何将它落地呢？下面我们就用一个服务的通用指标和告警设计为例，来看看RED方法下常见的服务指标和告警都有哪些。

如何落地RED监控？（通用指标与告警设计）

虽然具体的工具选择（如Prometheus, Grafana, SkyWalking, OpenTelemetry等）多种多样，但RED指标的设计思路是通用的。我们以一个常见的HTTP服务为例，看看如何设计其RED指标（遵循Prometheus指标规范）：

通用服务RED指标设计 (HTTP服务)

• http_requests_total (Counter类型): 记录处理的HTTP请求总数。
  • 核心标签 (Labels):
    • service_name: 服务唯一标识，如 “order-service”。
    • path: API路径模板，如 “/api/v1/orders/{id}” (注意使用模板，避免基数爆炸)。
    • method: HTTP方法，如 “GET”, “POST”。
    • status_code: HTTP响应状态码，如 “200″, “404″, “503″。
• http_request_duration_seconds (Histogram或Summary类型): 记录HTTP请求的处理时长。
  • 核心标签: 同上，status_code也可以用status_code_class（如”2xx”, “5xx”）来减少基数。

基于这两个基础指标，我们就可以通过查询语言（如PromQL）派生出RED指标：

• Rate (QPS):

sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method)

• Error Rate (5xx错误率):

(sum(rate(http_requests_total{service_name="<your_service>", status_code=~"5.."}[5m])) by (service_name, path, method)) / (sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method))

• Duration (P99延迟):

histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service_name="<your_service>"}[5m])) by (le, service_name, path, method))

基于RED指标的通用告警设计

告警的目的是及时发现问题并驱动行动。以下是一些基于RED的通用告警规则思路：

1. Rate告警 (请求速率异常)：
   • 规则： 服务总请求速率在过去10分钟内，与1小时前同一时刻相比，骤降70%以上（或骤增数倍）。
   • 级别： P1/P2 (视业务敏感度)
   • 告警提示： “[服务名]请求速率异常波动！”
2. Error告警 (错误率超标)：
   • 规则： 服务整体5xx错误率在过去2分钟内持续高于5%。
   • 级别： P0
   • 告警提示： “严重：[服务名]5xx错误率飙升至[当前值]！”
   • 规则： 某个关键API端点的5xx错误率在过去3分钟内持续高于10%。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]错误率过高！”
3. Duration告警 (延迟超标)：
   • 规则： 服务整体P99延迟在过去5分钟内持续高于2秒。
   • 级别： P0
   • 告警提示： “严重：[服务名]P99延迟高达[当前值]，用户体验受损！”
   • 规则： 某个关键API端点的P95延迟在过去5分钟内持续高于1秒。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]P95延迟过高！”

RED并非银弹：构建全面的可观测性

虽然RED方法非常强大，但它也不是万能的。一个完善的云原生可观测性体系，还需要：

• USE方法： 监控底层基础设施和节点的资源使用情况。
• 业务指标： 监控与业务直接相关的指标，如订单成功率、在线用户数等。
• 分布式追踪： 理解请求在复杂调用链中的完整路径和每一跳的耗时。
• 日志管理： 详细的日志是问题排查的“最后防线”。

将RED指标与这些数据源关联起来，才能形成从宏观到微观、从用户体验到系统内部的完整排查路径。

小结

在纷繁复杂的云原生世界，RED方法为我们提供了一套简洁、有效且以用户为中心的“导航系统”。它帮助我们聚焦于真正重要的服务健康指标，快速发现问题，优化性能，最终保障并提升用户体验。

希望今天的入门RED分享能对你有所启发。不妨现在就开始思考，如何在你的服务中实践RED监控吧！

你对RED方法有什么看法？在你的监控实践中，还有哪些好用的“三板斧”？欢迎在评论区留言交流！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。