Agent Behavior Engineering：当 Agent 的行为开始像代码一样被管理

过去一段时间，Agent 工程的主要叙事一直围绕能力扩展展开：让 Agent 读懂更大的代码仓库，调用更多工具，在浏览器和终端中执行操作，持续运行更长时间，再把复杂任务拆给多个子 Agent。模型能力不断增强，Agent 能完成的任务也越来越多。

这周没有哪一项更新单独看起来特别轰动，放在一起却出现了一个值得长期关注的变化。GitHub 开始让 Code Review Agent 读取仓库中的指令文件，并为它配置独立的运行环境和网络权限；Google 把 Prompt、规则和 Skill 变成可校验、可编译的构建产物；Microsoft 将专家经验封装成内置 Agent Skills，同时开始用隔离环境对 Skills 做回归评测。

这些更新处理的已经不只是 Agent 能不能完成任务。它们开始系统地回答另一组问题：Agent 应该按照什么规则行动，使用哪些工具，以什么顺序执行，什么时候需要验证，哪些操作必须经过确认，以及一次模型或 Skill 更新之后，原来能够正确完成的任务是否仍然有效。

Agent 的行为，正在成为需要持续定义、测试和治理的工程对象。

早期使用大模型时，Prompt 几乎是开发者能够直接控制的主要变量。结果不理想，就修改措辞、补充示例、调整角色设定，再重新运行一次。这套方法对于单轮问答和相对简单的生成任务很有效，也形成了 Prompt Engineering 这一整套实践。

Agent 出现之后，情况变得复杂了。一个 Agent 最终如何行动，取决于模型如何理解当前指令，也取决于系统向它提供了哪些上下文，仓库中存在哪些规则和规范，它能够调用哪些工具，当前环境允许它执行哪些操作，以及失败之后应该重试、换一种路径还是交还给人。

Prompt 仍然重要，但它只是这套系统中的一个组成部分。同一段 Prompt 放进不同模型、工具集合、代码仓库和运行环境中，可能产生完全不同的行为；即使所有输入都没有变化，模型的概率性也意味着两次执行不一定沿着相同路径前进。

团队真正需要管理的，正在从一段指令扩展为一整套影响 Agent 行为的工程资产。

这周最有代表性的变化，是过去散落在 Prompt、配置和个人经验中的内容，正在被纳入软件工程已经熟悉的版本管理、构建、测试和运行治理体系。

GitHub 在 Copilot code review: Customization and configurability improvements 中宣布，Copilot Code Review 已经可以读取 PR 分支中的 AGENTS.md、Agent Skills、REVIEW.md、CLAUDE.md 和 GEMINI.md。

这意味着团队可以把代码审查标准、测试要求、架构约束和工具使用方式保存在仓库里，和代码一起提交、评审和演进。Agent 如何理解项目、如何执行 Review，不再完全依赖平台内置的通用 Prompt。

Google 在 Evolving Spec-Driven Development: Conductor Now Supports Antigravity 中也展示了相似方向。Conductor 将 Skills、Rules、MCP Servers 和 Hooks 封装进 Plugin，同时把 spec.md、plan.md 等项目状态保存在代码仓库中，让不同 Agent 工具能够读取同一套规范和执行上下文。

当这些内容进入 Git，团队就可以追踪谁修改了规则、为什么修改、影响了哪些场景，并在出现问题时定位和回滚。Agent 的工作方式由此获得了和代码相似的版本历史与协作流程。

随着 Agent 承担的任务越来越复杂，系统 Prompt 也容易逐渐变成一个难以维护的大文件。安全约束、工具说明、领域知识、执行步骤和输出格式不断堆叠，修改一处可能影响另一处，遗漏依赖通常要到运行时才会暴露。

Google 在 Building scalable AI agents with modular prompt transpilation 中提出，可以把 Prompt、Skill 和规则拆成模块化文件，再通过 Transpiler 完成依赖解析、静态校验和最终 Prompt 的生成，并将这一过程接入 CI/CD。

这里真正重要的变化，不只是 Prompt 被拆成了多个文件，而是它开始拥有依赖关系、静态检查和构建失败机制。过去只能在 Agent 执行任务时暴露的问题，现在有机会在进入运行环境之前被发现。

Prompt 因此不再只是一段人工维护的文本，也开始成为软件构建过程的一部分。

Microsoft 在 Built-in Agent Skills Bring .NET and Azure Expertise into Visual Studio 中宣布，Visual Studio 18.8 开始内置由 .NET 和 Azure 团队维护的 Agent Skills，覆盖 Web API 开发、性能问题扫描、Azure 基础设施生成、部署前校验和日志查询等任务。

这些 Skills 并不是简单的提示词模板。它们封装了产品团队积累的工作流程、决策规则和安全边界，让 Agent 可以在具体工程任务中复用专家经验。

只要一项 Skill 开始被大量复用，它就会面对和软件产品相似的问题：谁负责维护，适配哪些模型与工具版本，依赖哪些环境，修改后会不会影响原有场景，以及不同团队使用时是否仍然可靠。

Skill 的价值不只在于“写出来”，还取决于后续的版本管理、效果评测和持续迭代。

Microsoft 在 How to test agent skills without hitting real APIs 中进一步处理了 Agent Skill 持续评测中的一个现实问题：当 Skill 需要调用真实 API 时，如何避免评测污染生产数据，同时保证结果可重复？

直接请求线上接口会产生费用，也可能修改生产数据；外部 API 的状态变化还会导致每次测试结果不同。Microsoft 的方案是通过 Dev Proxy 拦截请求，使用固定的本地数据模拟 API 行为，并在每轮测试后重置状态。这样既不需要修改 Skill 本身，也可以在隔离环境中反复执行同一组场景。

这已经很接近传统软件测试的做法：预先准备固定的测试数据和隔离环境，并在每轮执行后将状态重置。但 Agent 的测试对象更加复杂。它不能只判断最终字符串是否完全相等，还要检查 Agent 有没有选择正确的工具、是否按照合理顺序执行、有没有遗漏关键步骤、是否触发禁止操作，以及相同任务重复运行时的成功率是否稳定。

Agent 的测试对象由最终答案扩展到了完整执行轨迹。

当工程对象从一段 Prompt 扩展到 Skills、规则、上下文、工具、运行环境和 Eval，一种更系统的实践正在形成。

我们或许可以把它称为：Agent Behavior Engineering——Agent 行为工程。

这里的 Agent Behavior Engineering 还不是一个已经形成稳定定义的行业术语。目前业界更常见的是 Prompt Engineering、Context Engineering、Harness Engineering 和 Agent Engineering，但这些实践最终都在影响同一个对象：Agent 实际如何理解、决策、行动和验证。

Prompt Engineering 解决指令如何表达，Context Engineering 解决 Agent 在任务中能够获得什么信息，Harness Engineering 负责仓库、工具、环境和反馈循环。OpenAI 在 Harness engineering: leveraging Codex in an agent-first world 中展示的实践，就包括把仓库知识作为系统记录，为 Agent 提供可操作的开发环境，并通过测试、观测和反馈循环提高其工作可靠性。

Agent Behavior Engineering 关注的是这些手段组合之后产生的结果：Agent 在真实任务中如何行动，以及团队如何持续验证和改善这种行为。

它更像是一个上位的结果视角：如何让 Agent 在真实任务中，以团队期望的方式稳定行动。

Agent 的行为开始像代码一样被管理，并不意味着 Agent 会变成完全确定性的程序。

传统代码在相同输入和相同环境下，通常能够得到确定的输出。Agent 的执行过程包含模型推理、动态上下文和外部工具反馈，即使输入相同，也可能选择不同的实现路径。

因此，Agent 行为工程追求的不是逐行规定 Agent 必须怎么做，而是在管理一个概率系统：通过规则缩小可接受行为的范围，通过工具和环境提供正确路径，通过 Eval 检查行为分布，通过权限控制限制风险，再根据真实失败轨迹持续修正系统。

代码测试经常验证“结果是否精确等于预期”。Agent 测试还需要验证“在一组真实任务中，它是否有足够高的概率按照预期完成，并且没有越过边界”。

“像代码一样”强调的是工程生命周期：可定义、可版本化、可评审、可测试、可部署、可观测、可回滚。

它并不意味着把概率性的 Agent 强行变成确定性流程。

如果 Agent Behavior Engineering 会逐渐成为一项正式实践，团队需要积累的不只是更多 Prompt 和 Skills，还要形成一套完整的行为工程体系。

行为定义负责明确 Agent 应该如何工作。

除了任务目标，还要包括仓库规则、技术规范、工具使用方式、禁止事项、验证要求和人工升级条件。例如，修改代码前必须读取哪些文档，哪些目录不能改，提交 PR 前必须提供哪些验证证据，遇到哪些情况必须向人确认。

这些内容应该进入仓库，能够被评审、追踪和版本化，而不是散落在个人 Prompt、聊天记录和口头经验里。

行为执行负责为 Agent 提供完成任务所需的工具和运行边界。

它包括工具集合、权限模型、沙箱环境、网络访问、成本限制、工作流编排和人工接管机制。Agent 能做什么、不能做什么，哪些步骤可以自主完成，哪些操作必须经过审批，都需要在这一层明确。

模型能力越强，这一层越重要。一个能够修改整个仓库、访问多个系统的 Agent，如果缺少清晰的运行边界，带来的风险也会同步放大。

行为验证负责判断 Agent 是否按照预期完成任务。

团队需要从历史需求、典型任务、线上问题和真实失败案例中建立 Eval Set，并持续检查任务成功率、工具调用路径、验证通过率、人工介入次数和风险行为。

每次模型、Prompt、Skill、工具或工作流发生变化，都应该重新运行这些任务，确认新能力没有破坏原有行为。

通用 Benchmark 可以衡量模型的基础能力，但真正决定 Agent 能否进入团队研发流程的，往往是这些来自真实工作的内部评测集。

行为观测负责解释 Agent 在真实运行中发生了什么。

系统需要保留任务输入、上下文来源、工具调用、关键决策、验证结果、失败原因和人工介入记录，并进一步观察成本、延迟、成功率和不同仓库之间的差异。

GitHub 已经开始把 Copilot Coding Agent 和 Copilot Code Review 的使用指标下沉到仓库维度。在 Repository-level GitHub Copilot usage metrics generally available 中，企业可以按 Repository 查看 Agent 创建与合并的 PR，以及 Code Review 的活动情况。

未来团队评估一个仓库是否适合 Agent 工作，看的可能不只是文档是否完整，还包括行为规则是否明确、测试能否自动运行、验证结果是否可信，以及 Agent 的执行过程能否被观察、定位和接管。

这四个层次共同构成一个最小的 Agent Behavior Engineering 闭环：

定义 → 执行 → 验证 → 观测

观测到的新问题又会返回行为定义和执行环境，成为下一轮改进的输入。

Agent 能力仍然会继续增强。模型会处理更长的上下文，调用更多工具，运行更长时间，也会承担更复杂的研发任务。

能力越强，行为问题就越重要。一个 Agent 能修改整个仓库，也意味着它可能在更大范围内产生错误；一个 Agent 能访问更多系统，也意味着权限与审计必须更加清晰；一个 Agent 能长时间自主运行，也意味着团队需要知道它如何做出判断，以及出现偏差后如何定位。

真正决定 Agent 能否进入生产系统的，不只是它在一次演示中完成了什么，而是它能否在持续变化的任务、代码和环境中，保持可接受的行为质量。

模型能力决定 Agent 能走多远；行为工程决定它能否稳定地走进真实世界。