Jyoti Bansal认为，AI辅助软件工程中最具价值的环节将出现在代码生成之后。编码工具能够迅速创建和修改软件，但企业仍需对每项变更进行测试、扫描、审批、部署和观测，有时还要回滚。Harness正将自主工作智能体引入这些交付环节。
该公司将这种错配称为“AI速度悖论”：代码编写速度加快，发布流程却成为制约因素。Harness已经提供持续集成、交付、安全、功能管理、云成本及可靠性产品。智能体可以利用这些上下文，在整个生命周期中执行工作。
机遇在于成为围绕模型建立的受治理系统，而非在模型本身展开竞争。风险则是，拥有生产环境访问权限的智能体可能以机器速度犯错。班萨尔必须确保每项操作的权限均有明确边界、有据可查且能够回退。
软件交付是一个控制问题
一项变更要经过多个系统：源代码管理、测试、安全扫描、审批、部署和监控。人们需要花时间在这些系统间传递信息，并判断风险是否可以接受。智能体可以收集上下文并执行常规步骤。
Harness的优势在于身处能够直接观察政策与结果的流程之中。它可以获知哪项服务发生了变更、哪些测试失败、由谁负责，以及类似部署之后出现了什么情况。这种运营背景比单独使用通用代码模型更有价值。
平台不应假定推进得越快就一定越好。高风险系统可能需要职责分离和定期审查；低风险变更则可采取更积极的自动化。客户需要针对不同应用、环境和操作制定相应政策。
班萨尔应将自主权设计为分级授权。智能体可以先提供建议，随后在测试环境中执行任务，并在证明可靠后承担明确界定的生产任务。如果表现下降，这一过程应可逆转。
工作型智能体需要职责明确、范围有限的任务
Harness主张，智能体应专注做好一项任务，避免构建会产生非确定性行为的复杂网状系统。这种设计纪律十分重要。测试智能体、修复智能体和部署智能体可以分别配备不同的工具和权限。
专用型智能体更容易评估。客户可以衡量不稳定测试智能体能否识别真实的不稳定性，或成本智能体能否提出安全的建议。相比之下，既能编辑代码、又能变更基础设施并执行部署的通用智能体更难监管。
编排仍然至关重要。智能体需要传递证据和状态，同时不能暗中扩大权限。部署智能体不应继承安全智能体的凭据。中央策略层可以在维持权限边界的同时批准执行顺序。
界面应显示由哪个智能体执行、运行了哪个版本，以及哪些输入对其产生了影响。便于人类阅读的名称并不足够；审计还需要不可变的身份标识和日志。
每一项变更都应附有证据
企业需要知道一项变更为何获准。Harness可以将测试结果、漏洞、审批、成本影响和部署历史汇集为一份证据记录。该记录应在发布后继续保留。
智能体的解释必须指向底层数据。自然语言表达的置信度可能具有误导性。用户应能检查未通过的测试、政策或指标，并对结论提出质疑。
证据也有助于合规。受监管企业可以证明规定的审查已经完成，生产环境访问也已获得授权。如果日志完整且防篡改，自动化控制可以比人工核对清单更加一致。
客户应能将记录导出至审计和安全系统。Harness的价值在于组织这些证据，而非将其封闭在平台内。开放格式可以增强信任，减少对平台锁定的担忧。
回滚是一项运营能力
智能体难免出错。安全的交付平台会预设故障发生，并限制其影响。部署前，Harness可以记录配置、依赖关系和健康状态基线。发布后，它可以对比各项指标，并在超过设定阈值时回滚。
对于症状明确且先前状态经过测试的变更，自动回滚最为有效。数据库迁移、外部合同和数据删除可能难以逆转。智能体应识别这些情形，并要求更严格的审批。
回滚不应意味着调查结束。平台需要保留日志，标记此次事件，并防止同一变更未经修改便再次尝试。能从失败中吸取教训，也是可靠性的一部分。
客户应通过演练测试回滚机制。某项功能即使已在配置中启用，但若从未实际演练，也可能在事故发生时失效。Harness可以将这些模拟纳入准备度评分。
安全必须融入交付流程
机器生成的代码可能增加漏洞和安全问题的数量。开发完成后再扫描会造成任务积压。Harness正把安全环节整合进同一条流水线，以便在投入生产前确定风险优先级并完成修复。
智能体可以识别存在漏洞的依赖项、提出更新方案、运行测试并创建变更，但不应为了完成部署而暗中压下安全问题。安全政策需要独立的权威机制和公开透明的例外规定。
Harness还扩展了针对人工智能系统本身的控制，包括发现模型、智能体与工具连接。平台可以评估应用正在构建什么，以及构建过程中使用了哪些人工智能组件。
班萨尔必须避免夸大产品能够提供全面保护。运行时行为、第三方服务和新型攻击仍存在不确定性。产品应展示覆盖范围和盲区，而不是只给出一个安全评分。
成本治理是自主权的一部分
智能体可以持续消耗计算和云资源。编程智能体可能生成更多测试；可靠性智能体可能运行诊断；部署智能体可能创建环境。若没有预算约束，生产力提升可能导致成本失控。
Harness的云成本产品为其提供了相关数据。政策可以设置支出上限、调度工作负载，并要求重大变更须经审批。成本影响应与安全性和可靠性依据一并呈现。
优化智能体需要约束。删除闲置资源可以节省资金，却可能中断隐性依赖关系。建议应包含置信度、负责人和回滚方案。系统可以在观察后自动实施低风险的成本节约措施。
班萨尔应披露 Harness 如何对智能体活动定价。客户需要可预测的分级方案，以及按团队分配预算的能力。一个平台若对自身的人工智能收费讳莫如深，就无法令人信服地管理云成本。
平台战略可能增加复杂性
Harness在软件生命周期的各个环节提供超过15款产品。产品广度可为智能体提供丰富的上下文，却也可能令买家无所适从，并导致界面功能重叠。客户往往希望采用单一模块，而不必替换所有现有工具。
统一的数据、身份和策略层应在保留模块化采用方式的同时，使各模块协同运行。与源代码管理、可观测性和安全供应商建立开放集成至关重要。Harness的胜算在于协调异构环境，而非只能管理全套Harness技术栈。
在客户具备使用智能体所需的数据和流程之前，销售团队不应将其打包销售。就绪度评估可以发现责任归属、测试或回滚机制方面的缺口。成功部署比包含大量闲置模块的大额合同更有价值。
收购业务与内部产品需要采用一致的架构。班萨尔应消除重复工作流程，并公布迁移路径。平台整合应减少开发者必须作出的决策数量。
评估必须在客户环境中进行
在演示代码库中表现良好的智能体，到了大型单体代码库、受监管的开发流程或小众编程语言环境中可能失效。Harness应允许客户先运行历史回放和影子模式，再授予写入权限。
指标包括任务成功率、不安全操作、人工干预、节省时间和后续事故，并应按智能体和操作类型细分。总体生产率可能掩盖罕见但严重的故障。
模型变更后必须重新评估。Harness可能支持多家模型供应商，客户也可能自带模型。治理层应对模型、工具和政策的每一种组合分别进行版本管理。
独立测试能够提高可信度。应允许安全研究人员通过受控项目审查权限边界和指令攻击。研究发现需要配套整改和披露流程。
亚洲能够显现治理差异
Harness的业务覆盖亚太地区和印度，当地的全球企业、科技服务公司和高速增长的数字企业采用不同的交付方式。数据驻留、外包和监管责任也各不相同。
智能体可能跨越客户与服务提供商的边界采取行动。合同必须明确由谁授权访问生产环境，以及由谁接收日志。本地语言支持不仅关系到界面，也关系到证据处理和事件响应。
印度庞大的工程师群体既是市场，也是人才基础。智能体的应用应着眼于扩大工作范围、提高工作质量，而不是不加区分地取代审核。培训工程师设计政策并评估自主性，可以创造价值更高的岗位。
区域客户将评判该平台是否支持其云服务和工具选择。灵活的控制层能够拓展到封闭式技术栈难以立足的领域。
控制层必须保持问责
Harness处于有利位置，因为它正处在软件转化为运营承诺的关键节点。这一位置也使其成为关键依赖。服务中断或智能体遭到入侵，可能影响众多客户的生产系统。
公司需要具备强有力的隔离机制、服务可用性和透明的事件披露。Harness不可用时，客户应保留用于部署或回滚的应急通道。控制层不应成为导致全局瘫痪的单点。
Jyoti Bansal识别出了一个真实瓶颈：生成的代码只有在能够安全交付时才会创造价值。Harness可以成为治理这一转变的系统。它将通过范围明确的智能体、可核查的证据和可靠的回滚机制，逐步赢得权威。自主性应是控制能力得到验证后的结果，而非起始假设。
