AI Workflow Automation for Software Development: How to Hand an Agent a Whole Job

AI workflow automation hands an agent a whole job instead of a single step. It only ships software if you write the limits before the first run and check your delivery metrics after.AI 工作流自动化是将整个任务交给一个智能体，而不是仅仅处理其中一个步骤。只有在首次运行前设定好限制，并在运行后检查交付指标，才能真正实现软件交付。

Many teams think they have automated AI workflows, when they have really just added AI to individual steps of a manual process.许多团队认为他们实现了 AI 工作流自动化，但实际上他们只是在人工流程的各个环节中加入了 AI。

Ask a team whether AI changed how they handle dependency upgrades, and they will say yes. Then watch one happen.问问团队 AI 是否改变了他们处理依赖项升级的方式，他们会给出肯定的回答。但如果你去观察一次实际的操作，情况就不同了。

Monday morning, a bot opens a pull request bumping a library. An engineer pastes the changelog into an assistant, which explains what changed. The build fails. Someone pastes the failure into a second assistant, which suggests three fixes. A third engineer picks one, applies it by hand, and the upgrade merges Thursday. Four days to raise a version number by one.周一早上，一个机器人发起了一个提升库版本的拉取请求（pull request）。工程师将更新日志复制给 AI 助手，由其解释变更内容。构建失败了。有人将错误信息粘贴给第二个 AI 助手，它给出了三个修复方案。第三位工程师挑选了一个方案并手动应用，直到周四升级才合并完成。仅仅为了提升一个版本号，就耗费了四天时间。

Both assistants did useful work. Neither knew the other existed. The connecting was done by people, copying text between browser tabs. That isn’t workflow automation. But that is what most teams mean when they say AI handles their upgrades. A model makes the judgment calls, and a person carries each step’s output into the next.两个 AI 助手都完成了有用的工作。但它们彼此互不相知。连接它们的工作是由人完成的，通过在浏览器标签页之间复制文本。这并非工作流自动化。但这正是大多数团队所说的“AI 处理升级”的含义。模型负责做出判断，而人负责将每一步的输出传递到下一步。

The steps got automated. The workflow did not. AI workflow automation is what you get when the carryover between steps stops and you have one trigger, one run, one review at the end.步骤实现了自动化，但工作流没有。真正的 AI 工作流自动化是指消除了步骤之间的人工传递，实现一次触发、一次运行，并在最后进行一次审核。

When you remove the manual carryover steps, though, you’re removing a control nobody counted. Every handoff was a checkpoint where somebody looked at the work before passing it on, and removing the people removes those looks. Nobody wrote them down as a control, which is why nobody notices those look checkpoints are missing until something merges that should not have. So the workflow has to state what counts as finished, what a run may touch and who has to review and approve it.然而，当你移除人工传递步骤时，你也移除了一项未被计入的控制措施。每一次交接都是一个检查点，有人会在传递前查看工作内容，移除人工环节也就移除了这些检查。由于没人将其记录为一种控制措施，因此直到发生不该合并的内容被合并时，才有人注意到这些检查点的缺失。因此，工作流必须明确定义什么是“完成”、运行可以触及的范围，以及谁负责审核和批准。

What AI Workflow Automation Actually MeansAI 工作流自动化的真正含义

A traditional workflow runs on if-then steps. A commit lands, prewritten steps run in order, and every branch is a condition somebody wrote in advance. If the build fails, post to this channel. If the label says release, cut a tag.传统工作流运行在“如果-那么”（if-then）步骤上。当提交发生时，预设步骤按顺序运行，每个分支都是预先定义好的条件。如果构建失败，则发布到指定频道。如果标签显示为发布，则切出一个标签。

That works until a step needs a judgment no condition can express. Is this failure the same one as last week? Does this changelog touch code you actually call? Those questions have always fallen out of the workflow and onto a person.这种方式在步骤需要超出条件范畴的判断时就会失效。这次失败和上周的那次是同一个问题吗？这份更新日志涉及你实际调用的代码吗？这些问题一直以来都超出了工作流的范畴，必须由人工处理。

AI workflow automation puts a model in exactly those steps. The trigger, the if-then steps and the finish line stay where they were. Give that model tools and a definition of finished, and it becomes an agent.AI 工作流自动化正是将模型置于这些判断步骤中。触发器、if-then 步骤和终点线保持不变。为模型提供工具和“完成”的定义，它就成为了智能体。

The ambitious version, sold as agentic, hands the AI model a goal and lets it pick its own steps, delegating the whole run instead of one judgment call. That freedom can cause problems. For example, if the goal is simply to get the test suite to pass, the AI could decide to weaken an assertion instead of fixing the code. The goal was technically met, but it’s not what the team wanted.雄心勃勃的版本（通常被称为智能体化）会给 AI 模型一个目标，让它自行选择步骤，从而委托整个运行过程，而不是仅仅委托某一个判断点。这种自由可能会引发问题。例如，如果目标仅仅是让测试套件通过，AI 可能会决定削弱断言，而不是修复代码。目标在技术上达成了，但这并非团队想要的结果。

Point It at Delivery Work, Not Ticket Triage将其应用于交付工作，而非工单分类

The workflows teams automate first sit around the work rather than in it. It’s the low-stakes administrative sort of tasks: label the incoming issue, route it to a team, summarize a pull request, draft the stand-up note. These tasks have limited consequences. And each ends with a person making the actual change, so nothing the automation produced had to be correct. A mislabeled issue has never paged anyone at two in the morning.团队最先自动化的工作流往往围绕在工作本身之外，而非工作之内。这些是低风险的行政类任务：为收到的问题打标签、将其分配给团队、总结拉取请求、撰写站会笔记。这些任务后果有限。而且每项任务的最后都有人进行实际变更，因此自动化产出的内容无需绝对准确。一个打错标签的问题从未在凌晨两点触发过任何人的寻呼。

Delivery stages are harder because the finish line is harder. A run has to produce something that still works after the workflow closes.交付阶段更难，因为其终点线更难界定。一次运行必须产出在工作流结束后依然能正常工作的成果。

That last column decides whether a workflow is ready to automate. Ticket triage has a simple finish line: the issue has a label and is routed. Delivery is more complex. A change is not done until it works, has been reviewed and is safe to ship. AI can help carry out the steps, but it cannot define “done” for a team that has never agreed on what success looks like.最后这一列决定了工作流是否适合自动化。工单分类有一个简单的终点线：问题有了标签并被路由。交付则复杂得多。一项变更只有在能正常工作、经过审核且安全发布后才算完成。AI 可以协助执行步骤，但对于一个从未就“成功”达成一致的团队，AI 无法定义什么是“完成”。

Design the Workflow Around Its Judgment Steps围绕判断步骤设计工作流

Most of a workflow needs no model. Only the judgment steps do, where the decision cannot be written as a condition in advance. Everything else stays mechanical: fetching the branch, running the suite, opening a pull request, posting a comment. None of those improve when a model interprets them, and each step routed through a model is another place the run fails in a way you did not anticipate. A shell command that breaks will break identically every time, which is the most underrated feature it has.工作流的大部分内容不需要模型，只有那些无法预先写成条件的判断步骤才需要。其他所有步骤都保持机械化：获取分支、运行套件、打开拉取请求、发表评论。这些步骤在由模型解释时并不会有所改进，而每一个经过模型处理的步骤，都是运行过程可能以你未预料到的方式失败的潜在点。一个崩溃的 Shell 命令每次都会以相同的方式崩溃，这是它最被低估的特性。

Write the Workflow’s Limits Before the First Run在首次运行前写好工作流的限制条件

AI workflows need clear guardrails around what they can spend, change, access and execute, and someone needs to be responsible for maintaining those guardrails over time.AI 工作流需要在支出、变更、访问和执行等方面设置明确的护栏，并且需要有人负责长期维护这些护栏。

Before you let an AI agent act on code or systems, you need to define its boundaries. A run cannot set the limits that constrain it. Write them into the workflow definition.在允许 AI 智能体操作代码或系统之前，你需要定义其边界。运行过程本身无法设定约束它的限制。请将其写入工作流定义中。

• Budget - How many attempts, steps or tokens one run may spend, and what happens at that ceiling. An agent with unlimited retries eventually discovers that changing the test is easier than changing the code.预算：一次运行可以消耗多少次尝试、步骤或 Token，以及达到上限时会发生什么。一个拥有无限重试次数的智能体最终会发现，修改测试比修改代码更容易。

• Write paths - Which files a run may modify. Narrow paths keep each diff small enough for a human reviewer to read deliberately. Hand somebody 4,000 changed lines, and you’ll get an approval, not a review. Smaller, more focused changes are easier for humans to review properly.写入路径：运行过程可以修改哪些文件。狭窄的路径能保持每次差异（diff）足够小，以便人类审核员能够认真阅读。如果给某人 4000 行变更代码，你得到的只会是草率的批准，而不是真正的审核。更小、更集中的变更更易于人工进行正确审核。

• Commands and credentials - Which tools a workflow may call. These tools should be restricted. If agents have access to read issue reports, comments or other untrusted text, they could follow malicious instructions. OWASP’s prompt injection guidance recommends least privilege and human approval for privileged operations. Get this wrong, and the incident review shows your own service account making the change at three in the morning, with a valid token, because a stranger asked it to in a bug report.命令与凭证：工作流可以调用哪些工具。这些工具应当受到限制。如果智能体有权读取工单报告、评论或其他不受信任的文本，它们可能会遵循恶意指令。OWASP 的提示词注入指南建议对特权操作实施最小权限原则和人工审批。如果处理不当，事故审查可能会显示你的服务账号在凌晨三点使用有效令牌进行了变更，仅仅因为一个陌生人在 Bug 报告中提出了要求。

• Approvals - Which actions need a signature. Microsoft researchers sorted 1,535 developer answers onto a five-level scale. For development work, the median was Level 3: the AI writes the change, a developer approves it before it takes effect. Worth remembering the next time somebody calls approvals “friction.” Human approvals are intentional safety control.审批：哪些操作需要签名。微软研究人员将 1535 个开发者的回答按五级量表进行了分类。对于开发工作，中位数为 3 级：AI 编写变更，开发者在生效前进行批准。当有人称审批为“摩擦”时，记住这一点很有必要。人工审批是有意为之的安全控制。

Each limit needs an owner who can revise it. Rules that make sense today may become outdated later. If nobody is responsible for reviewing and updating the rules, temporary exceptions can quietly turn into permanent policy that nobody decided on.每个限制都需要一个可以对其进行修订的负责人。今天合理的规则未来可能会过时。如果没有人负责审查和更新规则，临时的例外情况可能会悄然变成无人决策的永久政策。

NIST’s AI Risk Management Framework calls for documented AI-risk roles for the same reason. Most teams can enforce all four limits with controls CI already audits: scoped job tokens, branch protection and environment approvals.NIST 的 AI 风险管理框架出于同样的原因要求设立记录在案的 AI 风险角色。大多数团队可以使用 CI 已经审计的控制措施来强制执行这四项限制：作用域作业令牌、分支保护和环境审批。

Measure the Workflow, Not the Agent衡量工作流，而不是智能体

The right way to assess AI automation success is by whether the whole software delivery process gets better, not by whether the AI itself seems fast or productive.评估 AI 自动化成功与否的正确方法，是看整个软件交付流程是否得到改善，而不是看 AI 本身看起来是否快速或高效。

Two DORA metrics tell you whether an automated workflow delivers:两个 DORA 指标可以告诉你自动化工作流是否有效交付：

• Lead time for changes: How long a commit takes to reach production变更交付周期（Lead time for changes）：提交内容到达生产环境所需的时间。
• Change fail rate: How often a change causes problems变更失败率（Change fail rate）：变更导致问题的频率。

Neither improves because a model writes faster, especially if developers have to spend more time reviewing and correcting what it produces. In a randomized trial, METR, an AI-evaluation research group, gave early-2025 coding tools to 16 experienced open-source developers on 246 real issues. The tools made the developers work 19% slower. The code arrived faster, but delivery got slower, because the time moved into reading and verifying output. Faster typing is not faster delivery, and only one of the two shows up in a number your business cares about.这两者都不会因为模型编写速度变快而改善，特别是当开发者不得不花费更多时间来审查和修正其产出时。在一项随机试验中，AI 评估研究小组 METR 让 16 位经验丰富的开源开发者在 246 个真实问题上使用了 2025 年初的编码工具。这些工具使开发者的工作效率降低了 19%。代码产出速度变快了，但交付速度变慢了，因为时间被转移到了阅读和验证输出上。打字变快并不等于交付变快，而且只有这两个指标中的一个会反映在企业关心的数字中。

So run a new workflow in approval-required mode and watch both numbers for weeks before granting more authority. Google’s 2025 DORA report found teams adopting more AI reported higher estimated throughput and higher estimated instability, without claiming AI caused either. That pairing is the risk in miniature: a workflow can produce more than your reviewers can check.因此，请在需要审批的模式下运行新的工作流，并观察这两个数字几周，然后再授予更多权限。谷歌 2025 年的 DORA 报告发现，采用更多 AI 的团队报告了更高的预估吞吐量和更高的预估不稳定性，且并未声称 AI 是造成这两者的原因。这种配对是风险的缩影：工作流产出的内容可能超过了审核人员的处理能力。

Don’t measure AI by how much code it produces; measure whether the entire workflow delivers software faster and more reliably.不要用 AI 产出的代码量来衡量它；要衡量整个工作流是否能更快、更可靠地交付软件。

Start with One Workflow从一个工作流开始

Don’t try to automate everything at once. Pick the workflow your team runs weekly and resents. Write its finish line in a sentence, its limits on one page and one owner’s name beside them. Run the workflow in approval-required mode, revise the limits that misfired, then use what you learned as a model for the next team.不要试图一次性自动化所有事情。挑选一个团队每周都要运行且感到厌烦的工作流。用一句话写下它的终点线，在一页纸上写下它的限制，并在旁边写下一个负责人的名字。在需要审批的模式下运行该工作流，修正那些失效的限制，然后将你的经验作为下一个团队的参考模型。

Choose the tooling after you define the workflow. Many products call themselves AI workflow platforms, but the label matters less than the controls they can actually enforce. Ignore the label and ask what the product makes reviewable: a run that stops at a ceiling, a directory it cannot touch, a required human approval before a change takes effect. Those answers tell you more than the product category does.在定义好工作流之后再选择工具。许多产品自称是 AI 工作流平台，但标签的重要性远不及它们实际能强制执行的控制措施。忽略标签，问问产品能让哪些内容变得可审核：运行是否在达到上限时停止、是否有其无法触及的目录、变更生效前是否需要人工审批。这些问题的答案比产品类别更能说明问题。

Learn About Progress Forge Orchestration了解 Progress Forge 编排

If you’re ready to move from isolated AI coding tasks to repeatable engineering workflows, Progress Forge (formerly Progress Agent Harness) is designed for exactly that shift. It orchestrates the AI coding agents your team already uses through structured workflows with visibility, governance and human review built in.如果你准备从孤立的 AI 编码任务转向可重复的工程工作流，Progress Forge（前身为 Progress Agent Harness）正是为此转变而设计的。它通过内置可见性、治理和人工审核的结构化工作流，来编排你团队已经在使用的 AI 编码智能体。

Explore the Progress Forge Early Access Program to see how it can help you put these ideas into practice.探索 Progress Forge 抢先体验计划，了解它如何帮助你将这些理念付诸实践。

Request a Demo申请演示