AI Agent 软件工程，是用工程化方法构建、评测、运行和治理 AI Agent 系统的一整套实践。它把模型、上下文、工具、记忆、编排、权限和监控当作可以设计、测试、版本化和复盘的部件，目标是让 Agent 在真实业务里稳定完成任务，而不只是在演示环境里跑通一次。
这个说法在行业里还没有统一的规范定义。常见语境有两种。企业讨论建设、采购和治理时，通常指构建 Agent 系统；研发团队讨论 AI 编程时，常指让 Agent 参与软件研发流程，学术界把它称为 Agentic Software Engineering，也有 SE 3.0 的说法。两种用法共享同一批工程能力，区别在于工程对象是 Agent 系统，还是被 Agent 改变的研发流程。先分清语境，后面的讨论才不会偏题。
AI Agent 软件工程是什么
把定义拆开看，有三个判断标准。
工程对象是一套系统。 模型只是其中一个部件，围绕它的上下文、工具、记忆、编排、权限和监控同样属于工程范围。任何一处变化，都可能改变最终结果。
交付物不止代码。 除了应用代码，还包括提示词、模型配置、工具描述、知识结构、评测集、权限策略和运行策略。这些内容需要像代码一样纳入版本管理，能够回滚和复现。
验收看任务结果分布。 单次演示成功，不能说明系统稳定。更有意义的指标是任务成功率、人工接管率、完成时延、单次成功成本和错误造成的损失。
以电商退款 Agent 为例。它需要识别用户意图，查询订单，核对退款政策，判断是否符合条件，调用退款接口，再把结果通知用户。遇到高风险订单，还要转人工处理。每个工具调用都要留痕，每次状态变更都要能追溯。这些环节里，模型负责一部分判断，剩下大量工作属于软件工程。
如果系统只按固定问题返回固定答案，它更接近知识库问答。当系统需要自己决定下一步、调用多个工具，并对结果负责，才进入 Agent 软件工程的范围。
两种用法：建设 Agent 系统，还是让 Agent 参与软件研发
| 用法 | 工程对象 | 典型问题 | 成功标准 |
|---|---|---|---|
| 构建 Agent 系统 | Agent 及周边基础设施 | 任务怎么拆、工具怎么接、结果怎么评测 | 任务成功率、成本、风险 |
| 用 Agent 做软件工程 | 研发流程与协作方式 | 哪些任务交给 Agent、人如何审阅 | 交付质量、返工率、周期 |
第一种用法更常见。企业要让客服、运营、数据分析或研发流程中出现能独立执行任务的 Agent，就需要建设一套可管理、可评测、可治理的系统。
第二种用法关注软件研发本身。IBM 在 2026 年 2 月的文章里，把 agentic engineering 定义为借助工程经验编排和监督 AI Agent 完成软件开发的过程。人负责设定目标、拆分任务、提供上下文、审查结果，Agent 负责执行具体任务并根据反馈迭代。
2026 年 11 月更新的 arXiv 论文提出了另一组说法。Agentic SE 包含 SE for Humans 和 SE for Agents 两种形态。人类在命令环境里编排和指导 Agent 团队，Agent 在执行环境里完成任务，遇到模糊或复杂取舍时再向人求助。研究重点落在角色、流程、工具和工件如何重新设计，目标是把 Agent 编程推进到更完整的工程协作。
对多数企业来说，先回答第一个用法更实际。把 Agent 系统建好、跑稳、管住，才有条件让 Agent 进入更复杂的研发流程。
Agent、Workflow 和 Prompt 的边界在哪里
Anthropic 在 2024 年 12 月的工程文章里给出了一组清晰区分。Workflow 是 LLM 和工具按预先写好的代码路径执行；Agent 是 LLM 自己决定处理过程和工具使用。
| 形态 | 谁决定下一步 | 更适合的情况 |
|---|---|---|
| Prompt | 人 | 单次生成、提取、改写、分类 |
| Workflow | 代码 | 步骤可以提前枚举，异常可以提前处理 |
| Agent | 模型 | 任务路径不确定，需要根据中间结果调整 |
一条实用的判断规则是，如果步骤能提前枚举，异常能提前写清，优先用 Workflow。只有任务路径需要根据中间结果不断变化时，Agent 的灵活性才值得额外的成本和不确定性。Anthropic 也提醒，Agent 系统会用更高的延迟和成本换取任务表现，简单方案够用时不必增加复杂度。
Prompt 仍然重要。它决定模型如何理解当前请求，但无法单独解决工具权限、状态保存、失败重试、结果验证这些问题。把 Prompt 写好，只是 Agent 软件工程的一个起点。一个能上生产的 Agent，还需要清楚自己能看什么、能调用什么、失败后怎么办、什么情况下必须停下来找人。
和传统软件工程相比，哪四件事变了
传统软件工程的经验仍然有用，但 Agent 系统改变了四个地方。
| 维度 | 传统软件工程 | AI Agent 软件工程 |
|---|---|---|
| 交付单元 | 代码与配置 | 代码、Prompt、模型、工具、知识、权限的组合 |
| 正确性 | 通过或失败 | 任务成功率、轨迹质量、成本分布 |
| 变更影响 | 版本升级 | 模型、数据、工具变化都可能让行为漂移 |
| 责任边界 | 功能验收 | 权限、审批、回滚、审计 |
这四件事会直接影响项目管理。模型升级可能改变工具选择，知识更新可能改变答案分布，工具接口调整可能让原本稳定的流程突然失败。因此，每次变更都要有回归评测，不能只看一次演示。
Agent 的行为来自模型与环境的交互。同一句输入，在不同上下文、不同工具返回、不同重试次数下，可能得到不同结果。团队需要接受这种概率性，用评测和监控去管理它，而不是期待一份固定输出。
一套 Agent 系统包含哪些工程部件
| 部件 | 要解决的问题 | 常见工程动作 |
|---|---|---|
| 任务与编排 | 目标怎么拆，什么时候停，何时转人工 | 任务分解、状态机、停止条件、交接规则 |
| 上下文与知识 | 模型该看到什么，信息是否可信 | 检索、实体建模、版本管理、口径统一 |
| 工具与接口 | Agent 能做什么，失败怎么返回 | 工具描述、参数校验、幂等、沙箱、MCP |
| 记忆与状态 | 长任务如何续跑，历史如何复用 | 会话记忆、长期记忆、任务持久化、恢复 |
| 模型与路由 | 用哪个模型，如何控制成本和时延 | 模型选择、降级、重试、路由 |
| 运行时与治理 | 谁在用，做了什么，能否追责 | 权限、审计、监控、成本核算 |
这些部件相互牵制。工具说明含糊，模型就会反复试错；知识口径不统一，同一个问题会得到不同答案；没有任务持久化，长流程中断后只能重来。
知识治理常被低估。企业把文档直接塞进检索库，容易把过期政策、重复条目和矛盾口径一起带进上下文。更稳妥的做法是先定义实体、指标和关系，再处理统一指标口径与版本管理。ThinkingAI 的企业级知识库采用 Schema-first 方式加工知识，以 SSOT 保证同一概念只有一处定义，并通过 ChangeSet 让更新可追溯、可对比、可回滚。这类基础工作不显眼，却直接决定 Agent 回答的稳定性。
工具接入也有类似问题。工具名、参数说明、错误码和返回结构，都是模型做判断的依据。接口设计得含糊，模型只能靠猜。对写操作还要增加幂等设计和沙箱验证，避免重试造成重复扣款、重复发券或重复删除。
评测与可观测，为什么决定 Agent 能否上生产
Agent 的质量需要被测量，运行过程需要被看见，这也是 Agent 管理中容易被忽略的部分。
评测回答的是做得好不好。团队需要从真实任务里整理场景集，写清预期结果和不可接受行为，在提示词、模型、工具或知识变更前跑回归，再对线上流量做抽样评估。评测集要覆盖顺利路径，也要覆盖信息缺失、工具报错、权限不足和用户中途改变目标的情况。
可观测回答的是为什么。一次任务涉及多轮模型调用、检索和工具执行，只看最终答案，很难判断问题出在哪一步。完整的 Trace 应该记录模型输入输出、检索内容、工具调用、执行状态、耗时、Token 使用和错误信息，并和用户会话关联起来。
2026 年 5 月更新的 arXiv 论文《Agentic Harness Engineering》提供了一个可参考的证据。研究团队固定基础模型，只迭代模型外的工具、中间件、长期记忆和可观测系统，十轮后 Terminal-Bench 2 的 pass@1 从 69.7% 提升到 77.0%。消融实验显示，增益更多来自工具、中间件和长期记忆，单纯修改系统 Prompt 的贡献有限。这个结果说明，模型外的工程结构能够独立影响 Agent 表现，也说明优化需要可归因，否则无法判断哪次改动有效。
以 ThinkingAI 的 AI Monitor 为例，它通过 Trace 采集调用关系、执行状态、耗时和 Token 使用，再从失败、长耗时和异常 Trace 中聚合问题，下钻到单次会话核对模型、工具和 Skill 的执行证据。这类工具的价值在于把结果发生之前的执行过程补全，让团队知道该改工具、改知识，还是改流程。
评测和可观测要一起用。只有评测，不知道线上为什么失败；只有监控，没有基线，也不知道当前结果算好还是坏。
权限、审计和人工接管，应该从第一天设计
Agent 会读数据、调接口、改状态，权限设计不能等到上线前再补。
- 最小权限：权限细到工具和操作，读写分离，凭据短期有效，避免一个 Agent 拿到整个系统的通行证。
- 人工确认：不可逆操作、超过金额阈值的操作、对外发送和数据删除，应该要求人工确认。
- 审计记录：记录谁发起任务、Agent 看到了什么、调用了哪些工具、改了什么、谁批准了结果。
- 回滚能力：写操作尽量支持幂等和补偿，先在沙箱验证，再进入真实环境。
- 数据边界：明确哪些数据可以进入上下文，哪些只能读取，哪些需要脱敏或本地处理。
一个实用规则是按错误可逆性分级。只读查询可以自动执行；可撤回的写操作可以在人工确认后执行；不可逆或影响外部用户的操作，应该保留双重确认和事后复核。权限模型和执行边界如果早期没有设计好，后面每接一个工具，风险债务都会增加。
企业落地：先判断条件，再决定自建还是用平台
企业要不要做 Agent 软件工程，先看任务，不先看模型。下面四个条件可以作为筛选框架。
| 条件 | 要问的问题 | 更适合先做的情况 |
|---|---|---|
| 任务频率 | 是否高频重复 | 高频、规则相对稳定 |
| 数字化程度 | 数据和工具能否被调用 | 系统有 API，数据可追溯 |
| 结果可验证 | 对错能否判断 | 有明确验收标准 |
| 错误可逆 | 出错能否撤回 | 可回滚，可人工接管 |
四项占得越多，越适合进入第一批试点。任务低频、结果难验证、错误不可逆的场景，可以先做辅助建议，不必急着让 Agent 自动执行。
推进方式可以分三步。第一步做建议型 Agent，只给分析和建议，由人执行。第二步做人审执行，Agent 准备好操作，人确认后提交。第三步做受控自动执行，只覆盖低风险、可回滚、结果可验证的任务，并保留监控和接管入口。
自建适合任务高度独特、工程团队完整、数据与合规要求严格，并且准备长期投入的企业。平台适合希望更快验证场景、直接获得知识治理、评测、监控和权限能力的团队。多数企业会采用混合方式，核心业务逻辑和私有工具自己掌握，通用运行时、知识和治理能力交给平台。
选平台时，模型列表只是其中一项。更需要核对的是知识如何治理、工具如何接入、评测怎么做、Trace 是否完整、权限能否细到工具、是否支持私有化部署。
ThinkingAI 的企业级 AI Agent 平台 Agentic Engine 支持创建和管理 Agent、多 Agent 协作和私有化部署。配套的企业级知识库负责把企业知识加工成 Agent 可调用的形态，AI Monitor 负责运行观测。ThinkingAI 已服务全球 1500 家企业，接入产品超过 8000 款。对于正在从单点 Demo 走向多场景建设的企业，这类平台能力可以减少重复搭建底层设施的工作。
团队要补齐哪些能力
这类项目通常需要五种能力，不一定对应五个岗位。
- 业务负责人定义任务、成功标准和异常处理规则。
- Agent 工程师负责编排、工具、上下文和运行时。
- 数据与知识工程师负责实体、指标、质量和版本。
- 评测与运营人员负责场景集、Trace 分析和回归。
- 安全与合规人员负责权限、审计和数据边界。
小团队可以一人兼多职，但这五项不能缺。缺了业务判断，Agent 会偏离真实任务；缺了评测，团队只能凭感觉迭代；缺了治理，系统很难进入核心流程。
常见问题
AI Agent 软件工程和 Prompt 工程有什么区别？
Prompt 工程主要优化模型在当前请求下的理解和输出。AI Agent 软件工程覆盖更长的链路，包括任务设计、工具接入、知识治理、状态管理、评测、监控和权限。Prompt 仍然重要，只是它属于系统中的一个环节。
没有算法团队，企业能做 Agent 软件工程吗？
可以，前提是把工作重心放在业务任务、知识治理和评测上。企业通常不需要训练基础模型，但需要有人能定义任务、读懂 Trace、设计评测集，并能判断工具和权限是否合理。使用成熟平台可以降低底层搭建难度，业务判断和验收责任仍然留在企业内部。
Agent 项目一定要自建平台吗？
不一定。任务独特、数据敏感、工程团队完整的企业可以自建。希望快速验证、缺少底层工程人员的企业，可以先用平台。混合方式也很常见，核心能力自建，通用能力采购。判断标准是总拥有成本、迭代速度和风险控制，而不是自建或采购本身。
怎么衡量一个 Agent 项目是否值得继续投入？
先建立基线，再比较任务成功率、人工接管率、完成时延、单次成功成本和错误损失。还要看团队是否因为 Agent 减少了重复劳动，或者缩短了业务响应时间。只有演示效果，没有稳定指标，很难判断项目是否值得扩大。
AgentOps 和 AI Agent 软件工程是什么关系？
AgentOps 更偏向 Agent 的运行、监控、评测和持续维护，是 AI Agent 软件工程的一部分。后者还覆盖前期的任务设计、系统构建、工具接入和权限治理，范围更完整。
参考资料
- IBM，《What is agentic engineering?》，2026 年 2 月 27 日，https://www.ibm.com/think/topics/agentic-engineering
- Anthropic，《Building effective agents》，2024 年 12 月 18 日，https://www.anthropic.com/engineering/building-effective-agents
- Hao Li 等，《Agentic Software Engineering: Foundational Pillars and a Research Roadmap》，arXiv:2509.06216v4，2026 年 11 月 2 日，https://arxiv.org/abs/2509.06216
- Jiahang Lin 等，《Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses》，arXiv:2604.25850v4，2026 年 5 月 18 日，https://arxiv.org/abs/2604.25850
