得物 Harness 实践：AI Agent 如何嵌入企业研发全链路

得物推荐的 Harness 实践显示，AI Agent 已从代码生成延伸至企业研发全链路。这套方案直接把需求拆解、测试验证、部署运维串成闭环，而非停留在局部提效。企业不再满足于单点工具，而是追求端到端流程重构。

Harness 实践把 Agent 拉入需求拆解环节

得物在 Harness 实践中，首先让 Agent 介入需求管理阶段。传统 AI Coding 工具主要聚焦生成代码片段，而 Harness 把 Agent 能力前置到需求拆解。Agent 接收自然语言描述的产品需求后，会自动拆分成多个可执行的任务单元，每个单元包含明确的功能点、依赖关系和验收标准。

这一步的核心是 Agent 与现有需求管理系统的对接。得物把 Jira 或类似工具中的需求票据直接喂给 Agent，Agent 则输出结构化的子任务列表。这些子任务不再是模糊的文字，而是带有优先级、估时和接口定义的机器可读格式。这样的输出能直接驱动后续的开发环节，避免人工反复翻译需求。

在实际操作中，Harness 的 Agent 会调用内部知识库来补充上下文。比如某个需求涉及支付流程，Agent 会自动拉取公司已有的支付模块规范和历史案例，确保拆解结果符合企业内部标准。这比单纯的代码生成前进了一大步，因为它把“理解需求”这个原本由产品经理和开发组长承担的工作部分自动化了。

得物观察到，经过 Agent 拆解后的需求，开发团队的理解偏差率下降明显。以前经常出现的“这个需求我理解错了”情况减少，因为 Agent 输出的子任务带有明确的验证点。整个需求阶段的耗时也缩短，原本需要多次会议对齐的内容，现在 Agent 一次就能给出初步版本，团队只需评审和微调。

这种延伸的关键在于 Agent 不再是孤立的代码助手，而是成为流程中的第一个节点。它把自然语言需求转化为结构化数据，为后面的测试和部署环节提供统一的数据基础。目前 Harness 在得物的落地中已覆盖了大部分中后台需求拆解，效果稳定。

测试验证阶段的 Agent 自动化闭环

进入测试环节后，Harness 的 Agent 构建了从代码提交到验证完成的自动化闭环。Agent 不再只是生成测试用例，而是全程参与执行和判断。

当开发人员提交代码后，Agent 立即触发对应的测试任务。它根据需求拆解阶段输出的验收标准，自动生成单元测试、集成测试和端到端测试脚本。这些脚本会运行在得物的测试环境中，Agent 实时收集结果并生成报告。

如果测试失败，Agent 不会简单报错，而是尝试定位问题根源。它可以分析日志、对比历史版本，甚至提出可能的修复补丁建议。这种闭环让测试不再是开发后的独立阶段，而是与编码并行的过程。得物的数据显示，引入 Agent 后，测试阶段的缺陷发现时间提前了大约 40%。

Harness 特别强调测试数据的管理。Agent 会根据需求上下文自动准备测试数据，包括构造模拟用户、数据库记录和外部接口返回。这些数据保证了测试的真实性，同时避免了手动维护测试数据的麻烦。

与需求拆解阶段不同，测试环节的 Agent 更注重执行力和判断力。它需要理解代码变更的影响范围，并决定哪些测试必须跑、哪些可以并行。这要求 Agent 具备一定的架构感知能力，得物通过向 Agent 注入系统架构图和模块依赖关系来实现这一点。

目前这一闭环已覆盖得物核心交易链路的测试，Agent 能独立完成 70% 以上的常规验证工作。剩余部分仍需人工介入，主要是一些复杂业务逻辑的边界case判断。

部署运维中的持续监控与回滚能力

部署和运维阶段是 Harness 实践的另一个重点。Agent 被嵌入到 CI/CD 流水线中，负责部署后的持续观察和异常处理。

代码通过测试后，Agent 会自动生成部署计划。它根据流量特征、依赖服务健康度等因素，选择合适的部署窗口和策略，比如蓝绿部署或金丝雀发布。部署完成后，Agent 立即启动监控模式。

监控不是简单的指标采集。Harness 的 Agent 会建立业务指标与技术指标的关联模型，比如把订单成功率和数据库连接数关联起来。一旦发现异常，Agent 能快速判断是代码问题还是外部依赖问题，并决定是否触发回滚。

回滚决策是 Agent 能力的重要体现。得物实践中，Agent 参考历史回滚记录、当前系统负载和业务影响范围，计算回滚的必要性和最佳时机。这比人工判断更快，也更少出错。

运维阶段的 Agent 还承担了日常巡检工作。它定期扫描日志、分析性能趋势，并在必要时提出优化建议。这些建议会以工单形式进入需求拆解环节，形成真正的闭环。

与前面环节相比，部署运维的 Agent 更强调实时性和安全性。它运行在生产环境，需要严格的权限控制和审计机制。得物通过沙箱机制和人工审核关键决策来平衡自动化程度和风险控制。

企业落地面临的安全与权限控制瓶颈

将 Agent 推入全链路后，安全和权限问题成为最大瓶颈。得物在 Harness 实践中发现，Agent 需要访问需求系统、代码仓库、测试环境、生产监控等多个敏感系统，这带来了明显的合规风险。

核心挑战在于权限的最小化原则。传统工具只需读写代码，而 Agent 需要跨系统操作。得物采取的应对方式是建立专门的 Agent 身份系统，每个 Agent 实例拥有独立的权限令牌，且令牌的有效期和操作范围都受到严格限制。

审计是另一个重点。Harness 会记录 Agent 的每一个决策和操作，包括输入提示、输出结果、调用的外部接口等。这些记录被集中存储，便于事后追溯。一旦发现异常行为，系统能快速定位到具体 Agent 实例并隔离。

合规方面，得物特别关注数据隐私。Agent 在处理需求和测试数据时，不能泄露用户真实信息。为此他们开发了数据脱敏插件，在 Agent 读取数据前自动替换敏感字段，同时保持数据的业务含义。

权限控制还体现在决策边界上。得物明确规定，Agent 可以自主决策的范围限于非核心链路，涉及资金、用户数据修改等操作仍需人工审核。这一规则通过配置文件动态管理，便于根据不同业务线调整。

这些措施让 Harness 得以在企业环境中安全运行，但也增加了实施复杂度。得物建议其他企业在引入类似方案时，从非核心系统开始试点，逐步扩大 Agent 的权限范围。

从工具到平台的可复制实施路径

得物的 Harness 实践提供了一条从单点工具向全链路平台演进的可复制路径。首先是选型阶段，企业需要评估现有研发工具链的开放程度。Harness 依赖于 API 丰富的系统，如果企业内部工具缺乏标准接口，实施难度会显著增加。

实施步骤上，得物建议分三步走。第一步接入需求管理系统，实现 Agent 拆解能力；第二步打通 CI/CD 和测试平台，构建验证闭环；第三步接入监控系统，完成运维环节。每个阶段结束都进行小范围试点，收集反馈后再扩大范围。

工具选型方面，Harness 本身是平台型方案，它不强制替换现有工具，而是作为协调层存在。这意味着企业可以保留 Jenkins、GitLab、Prometheus 等成熟工具，只需开发适配器让 Agent 能与之交互。

演进路径上，得物从辅助角色开始，让 Agent 承担重复性工作，逐步过渡到决策支持角色。最终目标是让 Agent 成为研发流程的默认执行者，人工只处理例外情况。这一路径对中文企业特别有参考价值，因为多数企业已有较完整的 DevOps 体系，关键在于如何把 Agent 融入而不是推倒重来。

得物还强调知识库建设的重要性。Agent 的表现高度依赖于企业内部文档、历史案例和最佳实践的数字化程度。没有良好的知识注入，再好的平台也难以发挥作用。

开发者角色与团队协作方式转变

Agent 进入全链路后，开发者的日常工作发生明显变化。得物观察到，开发者从大量重复编码和测试工作中解放出来，更多时间用于复杂问题解决和系统设计。

过去开发者需要手动编写测试用例、配置部署脚本、监控线上指标，现在这些工作大部分由 Agent 接管。开发者更多扮演审核者和指导者的角色，他们审查 Agent 生成的任务拆解、测试结果和部署计划，并在必要时介入调整。

团队协作方式也从线性流程转向并行协同。需求、开发、测试、运维不再严格按顺序进行，Agent 在各环节间自动传递信息，团队成员可以同时关注同一个需求的多个方面。这种协作要求开发者具备更强的沟通能力和系统思维，因为他们需要理解 Agent 的决策逻辑并提供有效反馈。

对中文开发者而言，这一转变既是机会也是挑战。熟悉 AI 工具的开发者能更快适应新角色，而习惯传统编码流程的开发者需要学习如何与 Agent 有效配合。得物通过内部培训和 Pair Programming 方式帮助团队过渡，重点培养“提示工程”和结果验证能力。

长期来看，这种转变可能重塑研发团队的构成。可能出现专门的 Agent 训练师角色，负责优化 Agent 的知识库和决策规则。同时，业务专家与技术人员的界限会更加模糊，因为 Agent 把部分技术工作标准化后，业务人员也能更直接地参与流程配置。

得物的实践显示，开发者对这一变化整体持积极态度。工作满意度提升的主要原因是减少了机械劳动，增加了创造性工作的比例。当然，初期也存在对 Agent 可靠性的质疑，需要通过持续验证来建立信任。

参考来源