1周半写64个PR、完成30%项目重构：一家成熟SaaS公司把Agent塞进研发全流程后

作者 | Jackie Calapristi

编译 | 蔡芳芳

编者按：当 AI 编程工具从“帮工程师写代码”进一步走向能够自主规划、实现、测试和排查问题的 Agent，软件工程真正发生的变化，可能已经不只是“写代码更快了”。Calendly 最近公开了其内部正在运行的一套 Agentic Engineering 实践：Agent 会先审查 Jira 需求、拆解任务，再并行写代码、跑测试、做 QA，最终由人类完成 Review 和 Merge；在 IAM 团队，仅一周半时间，Agent 就生成了 64 个 PR，完成了一个大型解耦项目约 30% 的工作。更值得关注的是，随着执行能力被进一步自动化，Calendly 发现工程研发的瓶颈再次发生了转移——从写代码，到需求对齐，再到如今的“判断力”。

Calendly 是一家成立于 2013 年的日程安排 SaaS 公司，核心产品通过连接用户日历，自动处理会议时间协调、预约和工作流等问题，被大量企业和个人用于销售、招聘、客户服务等场景。正因为它本身是一家拥有成熟产品、工程体系和生产环境的 SaaS 公司，Calendly 团队这次分享的 Agentic Engineering 实践，比单纯展示“AI 能写多少代码”更值得关注：他们讨论的是，当 Agent 真正进入一家成熟软件公司的 Jira、GitHub、CI 乃至生产运维体系之后，研发流程究竟会发生什么变化。

当代码越来越便宜，什么值得做、任务该如何定义、哪些工作可以交给 Agent、哪里必须由人接管，反而成为更稀缺的工程能力。这篇文章没有停留在“Agent 能不能写代码”的讨论上，而是给出了一家公司真正把 Agent 塞进研发生产流程之后，工程组织正在发生什么变化。以下是全文翻译：

1 引言

几个月前，我曾写过 Calendly 工程团队正在发生的一种转变：AI 编程助手每周都能为工程师节省数小时，而这些省下来的时间正在被投入到更好的产品思考、更快的验证，以及与产品和设计团队更紧密的协作中。我们把这种模式称为Product-first Engineering（产品优先工程），它背后的逻辑很简单：随着代码的生产成本越来越低，价值会逐渐转移到那些更难自动化的事情上——理解问题、进行权衡，以及真正把正确的东西做出来。第一波变化，包括减少样板代码、更快制作原型、更快完成验证，如今已经成为许多工程师默认的工作方式。但现在，情况又发生了变化。我们讨论的已经不再只是个人如何使用 AI 加快工作速度，而是开始真正把 Agent 嵌入工程研发工作流，让它们充当规划者、实现者、审查者和问题调查者，直接接入我们原本就在使用的软件交付系统。这篇文章要讨论的，就是这一切在真实实践中究竟是什么样子，而不是停留在理论层面：Agent 应该放在哪些环节？它们实际上承担并自动化了哪些工作？它们运行在哪些系统里？同样重要的是，哪些地方必须始终让人参与其中？事实上，人的参与现在比以往任何时候都更加重要，而且在可预见的未来都不会消失。

2 重新应用 Calendly 的「摩擦消除模型」

Calendly 最初的产品洞察就是消除摩擦。过去安排一次会议，通常意味着双方反复提出可选时间、查看日历，然后在一串“回复所有人”的邮件中来回沟通。我们打造了一款产品，把这些摩擦消除掉，让协调一次会议的成本几乎降到零。现在，我们开始对自己的工程研发流程提出同样的问题：从一个想法，到最终得到经过验证、真正可以工作的软件，这中间存在多少协调成本？其中又有多少可以被消除？两者之间的对应关系非常直接。对于用户而言，Calendly 降低的是最终安排好一场会议的协调成本；对于我们的工程团队来说，Agentic 系统正在降低从一个已经定义清楚的问题，到一个经过验证的实现方案之间的协调成本。我们现在希望消除想法、需求、实现、评审和最终可运行代码之间的所有摩擦。

我们并不是为了自动化而自动化，我们的目标是自动化那些重复性高、严重依赖上下文、又容易造成等待和延迟的工作，让优秀的人才能够把更多时间投入到真正能够创造价值的地方：判断、权衡、架构、产品思考以及用户体验。这个出发点非常重要，因为它决定了后面所有安全护栏应该如何设计。

3 当 AI 从「工具」变成「工作流」，发生了什么变化？

我们有必要准确解释一下 Calendly 所说的 Agentic Engineering 究竟是什么，因为这个词现在在整个行业里已经被用得非常宽泛。

从实践层面来看，工程师和团队首先定义目标、约束条件、上下文、验收标准和安全检查机制，然后，Agent 会进入人类原本使用的同一套系统，推动这些工作以一种摩擦更少、自动化程度更高的方式继续向前执行。执行过程发生在一套能够限定范围、接受审计、接受评审，并随着时间不断改进的系统中，而不是存在于一个会话结束就消失的聊天窗口里。

同样重要的是，我们必须明确 Agentic Engineering 不是什么。它不是“AI 把所有代码都写了”，不是不受限制的自主运行，也不是用 AI 替代真正的工程责任。任何一个名字出现在 Agent 辅助完成的工作上的工程师，仍然必须对这项工作负责，没有例外。

我们的核心判断是：真正发生的变化，不只是代码生成得更快了，而是我们开始拥有一个更加自动化的工程闭环，这个闭环拥有持久状态，并且在真正关键的节点内置了人工检查点。

4 Calendly 的 Agentic Engineering 闭环内部是什么样的？

新的工程闭环

Calendly 内部已经有多个团队各自独立探索，但最终逐渐形成了非常相似的工程闭环。通常情况下，团队会从一份 one-pager 或 Jira Ticket 开始，其中定义问题、约束条件、验收标准和已知风险。在任何代码真正被写出来之前，一个 Agent 会先审查这个 Ticket，寻找其中存在的歧义、遗漏的边界情况或缺失的实现细节。然后，一个规划 Agent（Planner Agent）会把已经批准的工作拆解成适合单个 PR 大小的任务。接下来，实现 Agent（Implementer Agent）会执行这些已经明确限定范围的任务，而且通常可以并行执行，运行在彼此隔离的 Worktree 或自托管 Worker 中。之后，一个QA Agent 或 Reviewer Agent会根据需求、测试套件以及 Repository 级别的指令验证输出。只有到了这一步，人才会进行最终的 Review、Approve 和 Merge，并决定哪些东西真正安全，可以发布到生产环境。这些工作并不存在于某一个临时聊天会话里：Jira 保存需求，GitHub 保存代码评审和修改历史，CI 保存验证结果，Repository 指令和共享规则保存 Agent 必须遵守的行为约束。所以，这是一套拥有持久记忆的闭环系统，而不是一个聪明的 Prompt。

5 Calendly 不同工程团队已经在如何使用自动化？

这并不是某种假想的未来状态。不同形式的 Agentic 工作流已经在整个 Calendly 组织内部真实运行。

CalTown：扩大「能够真正交付代码的人」的范围

Agentic 工作流改变工作方式最清晰的案例之一来自我自己的团队——Contacts。我们开发了一款内部工具，名叫CalTown，由 Max Conrad 主导开发。通过它，团队成员可以使用 AI 丰富 Jira Ticket，把 Ticket 分配给一个 Agent，然后让 Agent 完成整个开发流程并最终创建 Pull Request。在把 Branch 交回给人类评审之前，它甚至还会自动运行 Lint、类型检查和完整测试套件。

但这个案例真正特别的地方不只是自动化程度，而是谁能够使用它。我们团队里有两名过去从来没有真正交付过代码的成员——一位设计师和一位产品经理——现在已经通过 CalTown 创建并成功交付了 Pull Request。这是一个很有意义的信号：只要安全护栏和评审流程足够可靠，这套模式就能够扩大“谁可以安全地参与软件开发”的范围。它最大的价值并不主要体现在速度上，而是从上下文到实际执行之间出现了一条更加清晰、更加安全的路径，而且每一次都有真正的人类 Reviewer 和真正的 CI 参与其中。

不只是开发功能：Agent 也开始调查生产问题

Agentic 工作流并不只用于交付 Feature。Contacts 团队已经开始让 Agent 参与运维工作。比如，我们会让 Agent 对生产事故进行第一轮调查，把告警和最近的代码变更进行关联，沿着最有可能出现问题的代码路径进行追踪，并提出一个根因假设，这样人类工程师就不必一上来就在 Dashboard 和日志里毫无头绪地搜索。

这里的价值通常不是自动修复问题，而是更快理解问题。有时候 Agent 会返回一个诊断结果，有时候它会直接提出一个修复方案，还有一些时候，它会坦率地告诉我们调查还不够深入，所以它没有足够信心给出结论。实际上，正是这种诚实，让我们愿意放心地让 Agent 承担第一轮调查。无论最终是哪一种结果，它都会改变下一个接手这项工作的人所处的起点：从过去的“从零开始调查”，变成从一个已经形成的假设开始，然后快速确认或者纠正它。

IAM：目前量化效果最明显的案例

同样的模式也开始出现在其他团队里。虽然每个团队采用的方式有所不同，但底层思路是一致的。我们的 Identity and Access Management（IAM，身份与访问管理）团队目前正在运行 Calendly 内部量化效果最明显的 Agentic Execution 案例。大约一周半时间里，Agent 生成了 64 个 Pull Request，其中 37 个已经 Merge，另外 27 个仍在 Review，完成了一个“将 IAM 数据模型从 Monolith 中解耦”项目的大约30%。这些工作全部运行在一个专门的 Service Identity 下，并且仍然必须经过两个人工 Review Gate，所以，无论 Agent 做了多少工作，责任从来没有转移给工具。

Platform、Reliability 以及更多团队

另一个团队也构建了类似的 Planner-Implementer-QA 闭环，并增加了 Ticket 优化和 Bug Triage 自动化。我们的 Platform 团队正在开发一套 Agentic Design System，让 AI 工具默认使用已经批准的组件，而不是悄悄重新造一个。他们还在自动化一项非常繁琐的工作：当共享 UI Library 升级版本时，自动更新所有使用它的 Repository。

另一个团队正在试验每天自动扫描 Production Bug Backlog，只有当 Agent 对修复方案的置信度超过一个很高的阈值时，它才会提出 Fix，否则就把问题留给人类。

我们的 Reliability 团队则正在构建可复用的 Skills，教 Agent 如何完成定义清晰的任务，例如搭建 Load Test。其中一些 Skill 已经真正生成了测试套件，而且这些测试已经被 Merge 到 Production Service 中。

所有这一切下面，还有一层共享基础设施

所有 Agentic 工作流的底层都运行在一个共享基础设施之上。Calendly 维护着一个全公司共享的 AI Rules 和 Skills Repository，任何工程师都可以向其中贡献规则，也可以从中调用。同时，我们还拥有一套 Evaluation Framework，用于检查 AI 辅助 Code Review 是否真的能够发现问题；以及一套 Orchestration Pattern，用于把 Spec 或 Epic 转化成范围明确、可以 Review 的工作任务。这些案例使用的工具并不完全相同，真正共同的模式是：在每个团队自己的工程闭环中，利用 AI 消除最重复、最依赖上下文、最容易造成延迟的工作。

6 Agentic 系统出现以后，瓶颈转移到了哪里？

在上一阶段的变化中，我们已经看到瓶颈从写代码转移到了对齐（Alignment），也就是开会、写文档和来回沟通，确保所有人对于“究竟应该做什么”形成一致理解。到了 Agentic 阶段，执行能力再次大幅扩张，于是瓶颈又一次发生了转移。这一次，瓶颈变成了判断力（Judgment）：真正值得做的东西是什么？哪些事情可以安全自动化？哪些问题应该升级给人类？哪些工作从一开始就应该完全由人来完成？到了这里，整个故事实际上变得更加技术化，而不是更少技术化。因为当执行越来越便宜时，需求质量、Scope 质量和 Review 质量反而变得更加重要。把一个模糊的 Ticket 交给一个速度极快的 Agent，并不会让你更快得到正确结果，它只会让你更快得到一个错误结果。

7 好需求与好护栏

当思考工作已经被充分完成时，自动化才能发挥最好的效果。这当然不是什么新的工程原则，但是 Agentic Workflow 会把这个原则变得异常残酷——过去手工开发有时候还能容忍的模糊之处，在 Agentic Workflow 里很难继续混过去。一个强大的 Agentic 系统需要清晰的问题定义、良好的验收标准、能够被拆解成单个 Pull Request 大小的任务、明确的 Non-goal 和约束、Audit Trail、Review Gate，以及清晰的人类责任归属。

我们已经不得不接受一个非常实际的变化：**现在的 Ticket 必须同时写给人和 AI 看。一个能够减少人类理解歧义的 Ticket，同样能够减少 Agent 的歧义，反过来也一样。**这并不只是一种理念。独立研究也证明了为什么护栏如此重要。CodeRabbit 的一项行业研究分析了数百个 Pull Request，发现AI 辅助生成的 PR 在 Review 中暴露出来的问题数量，大约是完全由人类编写的 PR 的 1.7 倍，其中逻辑错误出现的概率大约高出 75%。另外一些安全研究则发现，相当一部分 AI 生成的代码样本会引入已知类型的安全漏洞，而且使用参数更大、能力更强的模型，也并不能稳定解决这个问题。这些发现都不是在证明不应该使用 AI 工具，恰恰相反，它们证明了为什么 Review Gate、有限权限以及人类对最终结果负责，并不是可有可无的额外开销，它们恰恰是让自主性真正可用的前提。简单来说，好的护栏才能让速度变得值得信任。系统可靠性并不主要来自一个聪明的 Prompt，而更多来自一套强大的运行规则——这些规则不能依赖于“每一次 Prompt 都足够聪明”。

8 这会如何改变工程师？

工程师花在“把需求人工翻译成样板代码”上的时间会越来越少。相应地，他们会把越来越多的时间用于成为 Planner、Reviewer、Debugger、意图编辑者、系统思考者和风险发现者。但如果背后没有深厚的技术能力，这一切都无法运作。在任何 Agent 输出进入生产环境之前，仍然必须有人拥有足够的知识，能够信任它、纠正它，或者推翻它。但工程师的杠杆正在发生变化，越来越重要的能力变成：正确地定义问题、正确地约束执行，以及严格验证结果。在 Calendly 一次覆盖十多个团队、数十名工程师的内部试验中，我们非常明显地看到了这种模式：这些工具带来的变化，与其说是让工程师把原来的工作做得更快，不如说是改变了工程师工作的方式。绝大多数工程师表示，他们仍然会像 Review 一个团队成员提交的 Pull Request 一样，严格审查 Agent 生成的内容。这种本能是完全正确的：把 Agent 输出当作任何一个协作者交出的第一版草稿来处理。随着 Agentic Workflow 不断扩大，这也正是我们希望继续强化的行为方式。

9 结论：下一个瓶颈仍然是判断力

现在，我们的工程团队提出的问题已经变了。过去更多是：“我们能不能把它做出来？”或者“我们应该怎么做？”现在越来越多的问题变成：“这真的是正确的东西吗？”“这个问题的定义方式正确吗？”“我们构建它所依赖的系统，是否拥有正确的约束？”“真正合适的人，是否在真正关键的时刻参与 Review？”随着整个软件行业的执行能力越来越充裕、执行成本越来越低，那些从来都很难伪装出来的东西——产品判断力、技术判断力以及组织清晰度——反而变得更加重要。执行从来都不是真正稀缺的资源，真正稀缺的是判断什么事情值得被执行。

10 致谢

感谢整个工程组织中所有以好奇心、健康的怀疑态度以及谨慎精神尝试 AI 辅助和 Agentic Workflow 的同事。正是这种组合，使得本文中的案例来自真正运行中的系统，而不是猜想。特别感谢那些参与构建共享 Agent 配置、Self-hosted Worker、Planning Workflow，以及 Contacts、IAM、Scheduling and Availability、Frontend Platform、Ecosystems、App Platform 和 SRE/DRE 团队中 Operational Pattern 的同事。也感谢所有在真实代码库中测试这些 Workflow 的工程师，他们逐行 Review Agent 生成的 Plan 和 Pull Request，并且坦诚分享哪些方法有效、哪些方法无效。同时感谢我们的产品、设计、基础设施、安全和平台合作伙伴，是他们帮助我们建立了必要的清晰度和 Guardrail，让这样的实验真正有价值，而不是变成鲁莽的冒险。和上一轮变化一样，这一次转型同样是一项团队工作，它建立在信任、共同学习和负责任的持续迭代之上。

11 下一步

我们会继续优化覆盖 Planning、Implementation、QA 和 Operational Investigation 的 Agentic Workflow。这意味着，我们会继续投入建设更强的任务定义、更清晰的验收标准和更完善的 Review Practice，让 Agent 能够在明确边界内安全工作；同时进一步扩大已经证明具有明确价值的工作流，包括 Alert Triage、Incident Investigation、Codebase Research 和 Backlog Refinement。

我们还在努力让 Jira、GitHub、Slack、Observability Tools 和开发环境更好地协同工作，这样 Agent 就可以运行在人类已经信任的同一套持久化系统中。与此同时，我们仍然会谨慎判断什么地方适合 Agentic Workflow，什么地方使用轻量级 AI Assistance 已经足够，以及什么工作应该继续完全由人类主导；并继续构建必要的 Guardrail，让团队能够安全使用更高程度的自主性，同时又不会失去责任归属。从 Calendly 创立的第一天开始，我们的主线其实从来没有改变：消除摩擦，让人能够专注于真正重要的工作。

https://calendly.com/blog/what-agentic-engineering-looks-like-in-practice

声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。