Harness

从 LOOP 到图探索：算法模型 AutoResearch 自进化系统架构演进之路

一个算法团队参考 Karpathy 开源的 AutoResearch 原型，把「让 AI 自己改训练代码、跑实验、看指标、决定下一步」的循环搬进企业云端训练平台。最初的单线程循环有三个毛病：规则靠自然语言提示不可靠、与企业云环境不匹配、同一时间只能试一条路。他们三个月重构三次，最终改成「图探索」：主 Agent 把大问题拆成几个互不重叠的假设，交给子 Agent 并行各自训练、互不干扰，再由主 Agent 汇总对比做决策，并用状态文件和冻结的评估代码保证无人值守时可信、可回溯。在结构完全不同的两个业务建模项目中，单任务耗时比人工基线分别减少约 85% 和 83%，其中一个方案已推全上线并有收益，另一个在全部 12 个预估目标上超过人工基线。

Harness 推出 VegaLoad：开源负载测试工具

Harness 发布了一款叫 VegaLoad 的免费开源负载测试工具，采用 Apache 2.0 许可证，由其韧性测试团队开发。以前做负载测试往往要另外找工具、把脚本放在别的仓库，还得提工单排队等运行，很多服务没做压测就上线了。VegaLoad 把压测脚本变成一个放在代码旁边的小文件，AI 编程助手可以直接写测试、运行测试，返回通过或失败结果和一份 HTML 报告，测试在本机跑，还能设延迟和错误率上限拦截合并或发布。对开发者来说，压测能在几分钟内试起来，代码可读可改；不过若需要多机集群压测或跨团队历史记录，则要另用 Harness 的商业产品。

受治理的软件工厂：Harness 与 Cosmos

Harness 和 Cosmos 想把软件开发变成一条受管控的“流水线”：Harness 负责把代码变更安全送进生产环境，并在构建、测试、安全和部署等环节留下证据；Cosmos 负责用事件触发并协调各种 AI 代理，按固定流程把规格变成 PR、把告警变成修复。过去企业担心自动化流程不可信、不可控，这次的做法是让代理只在受限制的容器里运行、令牌按次发放、策略不通过就不执行，变更失败还能自动回滚。对读者来说，这意味着未来更多重复性工程工作可由流程化代理完成，人只在关键检查点审批，但目前材料没有说明具体可用时间、价格或独立验证结果。

Harness 收购 Augment 编程智能体，但最佳功能尚未发布

Harness 宣布收购了 Augment Code 的编程智能体产品，包括 Cosmos 软件工厂等，想解决的是：代码生成变快了，但测试和发布流程没跟上，反而成了瓶颈。他们计划让智能体在写代码时参考过去的部署失败记录，自动修复问题，但这项整合功能还没上线，具体怎么交换信息、权限怎么分配都没说清楚。目前 Cosmos 仍可在原网站使用，程序员依然要人工审核代码。对读者来说，如果团队用这套工具，现在只能用到基础功能，真正好用的部分还得等。

Harness 收购 Augment Code，推进自主软件开发生命周期

Harness 收购了 Augment Code 的部分资产，包括 Cosmos、Auggie CLI 和代码上下文引擎。以前，AI 写代码和把代码安全部署到生产环境是两件分开的事，中间要人工搬运信息。现在 Harness 想把这些环节连起来：让 AI 代理从工单或 bug 出发，自动规划、写代码和测试、提 PR，再交给 Harness 的交付、安全、成本等代理一路管到上线。对读者来说，这意味着软件开发可能从「AI 帮写代码」走向「AI 跑通整条流水线」，但具体开放时间和可用范围原文未说明。

判断而非生成：在 Jev 上重建 AI API 分类器

安全平台 Harness 的 AppSec 团队用自研决策模型 Jev 替换了原来生成式大模型做的「是/否判断」环节，用来识别客户 API 里哪些在和 LLM 通信。原来这条流水线要先用两次 LLM 摘要、再做分类，成本高、延迟大，而且模型自报的置信度几乎不能用来判断对错。换成 Jev 后，系统不再让模型写文字，只输出一个概率：每条 API 的判断成本比原流水线降约 1200 倍，比单次 LLM 方案降约 150 倍；出错的样本都落在 0.3–0.8 的不确定区间，只占 3.4%。对读者来说，这提供了一种思路：把流水线中重复的「判断」和「生成」拆开，用专门的决策模型替代，能大幅降本，同时保留可回滚的接口。

为什么工程师无视云成本治理（以及如何解决）

Harness 发布博客文章，解释工程师为什么常常忽略云成本：传统 FinOps 工具把成本数据放在独立的财务仪表盘里，开发者得中断写代码去查，而且反馈往往要等 30 天才来，和日常交付节奏脱节。文章提出的做法是把成本信息“左移”进 CI/CD 和 IaC 流程：在合并请求合并前就评估这次改动是不是申请了没批准的实例类型、会不会超预算，超了就自动拦截或交给负责人审批；同时用 Harness Cost Management Agent 在服务级别做实时成本可见性。对平台团队来说，意义在于不用牺牲开发速度也能让开发者对云支出负责。目前文中提到的产品能力和模式来自厂商博客，具体发布时间和可用范围原文未说明。

完成交付：Harness 2026 年 9 月发布内容汇总

Harness 在 30 天内发布了 102 项产品更新，差不多每 7 小时就有一项。它解决的是：代码写得很快，但后面的构建、测试、安全检查、审批和部署仍然很慢。这个月它把合并队列、命令行工具、基础设施密钥扫描等能力补齐，还让 ChatGPT 可以直接管理 Harness 流水线。对开发团队来说，等待构建和部署的时间可能缩短，安全扫描也更容易内嵌进流程。部分功能已可用，但具体开放范围原文未说明。

为什么工程师忽视云成本优化，以及如何解决

这篇文章讨论了一个常见现象：工程师常常不关注云账单，不是因为不在乎，而是因为账单数据藏在财务系统里，和他们日常写代码、发版本的工作完全脱节。于是当月底账单超支时，财务发来一堆看不懂的资源编号，工程师也没有动力去查。对于 AI 相关花费，比如模型调用和编码工具的费用，这个问题更严重，因为没法像给服务器打标签那样给每一次提问打标签。文章建议把成本信息提前放进开发流程里：提交代码时自动显示这次改动会让每月多花多少钱，并设置规则自动关掉闲置资源。这样工程师就能在做决定时顺手考虑成本，而不是事后被追着算账。文中提到 Harness 的 Cost Management Agent 作为解决工具，但具体效果和实施细节原文没有展开说明。

Oracle 数据库 DevOps：自动化 Oracle 模式变更

很多企业还在用老办法改 Oracle 数据库结构：手写 SQL 脚本、DBA 审批、午夜窗口执行。Oracle 的 DDL 不自带事务回滚，还有 RAC 集群、Data Guard 备库等特殊限制，让自动化比 MySQL、Postgres 更麻烦。Harness Database DevOps 通过 JDBC 连上 Oracle，把模式变更放进 Git 版本控制和 CI/CD 流水线，配合策略即代码护栏、预检校验和测试过的回滚脚本，让改数据库和改应用代码一样快、一样安全。对读者来说，如果团队正被 Oracle 手工改表流程拖慢，这套思路提供了一条可参考的落地路径。原文未说明该产品当前是否已正式可用或仅演示。

将软件交付上下文带入 ChatGPT 和 Codex

Harness 推出面向 OpenAI 的连接器，让 ChatGPT 和 Codex CLI 能直接查看 CI/CD 流水线状态。以前排查构建失败，你得在两个工具间来回切换、翻日志找配置；现在可以在同一个对话里问清楚哪一步失败、原因是什么，还能在授权后新建、修改或执行流水线。所有操作都沿用你原有的 Harness 权限，通过 OAuth 登录，敏感改动需要单独确认。需要 Harness SaaS 账号并开启 OAuth，以及允许该集成的 OpenAI 工作区。

Harness 如何编排 LLM 安全扫描

传统代码扫描器只能靠规则匹配找已知模式，而大语言模型能顺着程序逻辑追踪攻击者可控的输入是否真的能到达危险位置，因此能发现规则没覆盖的漏洞。但模型本身不稳定：同一份没变的代码扫两次，结果可能不同，耗时和花费也难预测，没法直接用在每次提交都跑的自动化扫描上。Harness 的 Security Test Orchestration（STO）在模型外面加了一层编排：控制扫描什么时候触发、只扫改动范围、每步怎么约束、结果怎么统一，变成可比较、可信任的扫描。用 GPT-5.5 对三个故意留漏洞的测试应用跑基准，增量扫描比全量扫描最高省约 83% 费用、快约 72%，且没有漏掉全量扫描找到的问题；连续跑 10 次时增量方案比全量便宜约 75%。目前该能力基于 OpenAI Codex Security，配合 Mythos 代理插件，以安全扫描技能方式调用，具体开放范围和价格原文未说明。

漏洞修复与漏洞缓解：区别何在

Harness 发布了一篇博客，解释漏洞“修复”和“缓解”的区别：修复是打补丁或升级，彻底消除漏洞；缓解则是隔离、封堵或关闭功能，让漏洞难以被利用，但漏洞本身还在。博客说，当补丁还没有、修复需要停机窗口，或攻击路径本来就不通时，可以先选缓解；但每个缓解措施都要有负责人和到期日，否则临时措施会变成永久隐患。对开发团队来说，这能帮助决定什么时候必须真正修、什么时候可以先顶住，而不是把风险一直存着。文中还提到 Harness 的安全测试编排可对接 40 多个合作扫描器，并引用调查称：最频繁使用 AI 编程工具的人群中，50% 表示采用后漏洞和安全事件变多了。

为什么面向工程师的云成本优化会失败

这篇文章解释了工程师为什么常常忽视云成本：账单数据往往延迟几周才出现，而且是汇总后的数字，跟具体哪次提交、哪个部署造成的花费对不上号。作者提出的解决思路是把成本信息“左移”，也就是在代码合并和 CI/CD 流程里直接显示这次改动会多花多少钱，让工程师在写代码时就能看到并负责。文章还提到，Kubernetes 里把 CPU、内存请求设得过高，会导致云账单悄悄上涨，但普通账单面板查不出是哪个部署干的。Harness 被作为能帮助实现这类开发者视角 FinOps 的工具提及。

Harness 与 AWS AgentCore 集成：为 AI Agent 提供动态发现与运行时安全

Harness 宣布与 Amazon Bedrock AgentCore Gateway 集成，帮助企业在 AWS 上发现并保护 AI Agent、工具和资源。以前企业把大量 Agent 从实验推向生产，但传统安全手段只能检查单个请求，无法判断 Agent 一连串看似合法的操作是否被恶意操控。新集成能在 Agent 决策变成行动的关键位置自动盘点 AI 资产、实时检测提示注入和敏感数据泄露，并关联客户端、工具和数据还原事件全貌。对安全团队来说，他们可以像查看地图一样持续掌握 AI 攻击面，而不必手动追踪。

Agent Comms：跨 Harness 的 LLM 智能体通信网格

ExaDev/agent-comms · Cross-harness communication mesh for LLM agents. Rooms, DMs, presence, and visibility.

Agent Comms 为不同 harness 中的 LLM 智能体提供一套基于 localhost TCP 的通信网格，支持注册与发现、房间、私信、在线状态和可见性控制。每个 bridge 实例作为对等节点接入，首个绑定固定端口的实例担任协调者负责介绍新节点，数据连接均为节点间直连；消息通过 TCP 直接推送，无需守护进程或文件系统轮询，进程离线期间的消息会进入复制的投递队列并在重启后重放。项目提供 pi、Claude Code 及通用 MCP 的安装接入方式，并附带可扩展新 harness 的桥接能力。

开发者门户安全与治理最佳实践

Harness 在一篇博客中介绍了如何在不拖慢开发团队的前提下，加强开发者门户的安全、合规与可审计性。问题在于：当基础设施模板和脚本散落在各处，开发者容易用错配置、权限过大，导致数据库密钥泄露或跳过安全检查。解决办法是把安全控制、自动审计日志和基于角色的权限直接嵌入内部开发者门户（IDP），让开发者走预设的安全路径，而不用手动审批。对读者的用处是：了解如何减少合规风险，同时让开发照常快速推进。文中提到的做法偏向最佳实践，并非一个具体可直接使用的新产品发布；部分细节原文未说明。

使用 Harness 与 Terraform 自动化创建 Docker 镜像仓库

本文介绍如何通过 Harness Pipelines 与 Harness Terraform Provider 构建一条全自动 CI/CD 流水线：在 CI 步骤中内联运行 Terraform 动态创建唯一命名的 Docker 镜像仓库，构建并推送容器镜像，再将其部署到 Kubernetes，并通过输出变量与 Harness 表达式在各阶段间传递数据，全程无需手动操作 UI。