让 AI 自己做增长：基于OPC和Harness思想的自主增长系统探索

故事的起点是我们持续在围绕高德地图PC站做SEO优化，在探索各个方向上能带来增长的可能。偶然在某社媒上看到一个内容是关于一个人怎么利用AI自主发现需求并全程自主开发和上线APP的并能自动进入下一个提案的探索与执行。立马在我们的脑子中开始火星撞地球，决定在PC站SEO这个场景下借鉴这个思路，并且实践OPC（一人公司）。

发现增长机会、设计方案、编写代码、测试上线——这条完整的链路上，每个环节都需要专业能力和大量时间。传统的做法每个链路都需要有特定的人来参与或者先进一点是人工指挥多个AI工具来完成，但在 OPC 的思想下，AI Agent独立自主完成是可以有机会实现的一个路径。

因此我们尝试贯彻“一人公司”的设计理念，开始思考如何让 AI 自主发现网站的增长机会，自主生成提案，自主完成从需求文档到代码实现再到部署上线的全流程，中间加上合规风险监测，并且全程不需要人工干预？更进一步，这个系统能否周期性地重复这一过程，持续探索和迭代？

先说结论

结合我们的业务目标，我们基于Harness Engineering实现了这套业务流程图

为了验证系统的稳定性，我们前期先以”路书”功能为核心例子（旅行路线规划工具）进行验证。从输入提案，系统自主开始 PRD 编写到发布到日常环境，全程 0 人为介入，连续运行4小时, 实现路书应用，主流程无P0 Bug。

Harness Engineering是指围绕 AI Agent（特别是 Coding Agent）设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。

它解决的核心问题是：当 AI Agent 拥有了强大的代码生成能力后，如何确保其输出的可靠性、一致性和长期可维护性。

我们来看anthropic实践是如何落地的：

1. 构造Planner智能体，它接收简短的 1-4 句提示，并将其扩展为完整的产品规格说明。

2. 构造Generator智能体，Generator首先根据用户提示创建一个 HTML/CSS/JS 前端。

3. 构造Evaluator配备了 Playwright MCP，使其能够在对每个标准评分并撰写详细评语之前，直接与运行中的页面进行交互。在实际操作中，Evaluator会自主浏览页面，对页面进行截图并仔细研究实现效果，然后再给出评估结论。

4. 这些反馈随后作为下一轮迭代的输入，回传给Generator。

经典的Harness Engineering在让 AI 能够自主完成复杂任务，不再是一次性问答，通过反馈循环保证质量，在Harness Engineering思想之下，我们的自主增长系统需要更加细分的设计来贴合业务诉求：

1. 需要总控的Agent负责统筹和调度

2. 需要记忆系统和来记录执行过程和传递输入输出，记忆系统共享知识，上游产出自动成为下游输入

3. 需要拆分Agent，保持专业的人做专业的事，每个 Agent 专注自己擅长的领域

4. 需要增加专业skill，来在垂类方向上更加的准确，节约时间。

在实际的架构落地过程当中我们仍然要解决几个问题：

3.1.1 如何保障长任务的正常运行

整个生成项目的任务被定义成一个workflow， 通过状态机定义流程 + 子 Agent 分工 + 反馈循环迭代 + 独立评审门禁，来解决长任务的问题。

1. orchestrator负责监听和派发任务状态，同时在memory系统当中，以文件的形式记录运行的日志和流转过程。

2. orchestrator保证任务正常执行的机制：

下面是一个轮询配置

child_run_protocol:                                                              ack_timeout_seconds: 300           # 5分钟没确认 → 超时                        default_stall_timeout_seconds: 1200 # 20分钟没进展 → 卡死                      orchestrator_poll_interval_seconds: 60  # 每60秒检查一次  

steps:  - state: PRODUCT_DEFINING ← 状态1：产品需求定义   agent: product_agent  condition: decision == APPROVED && guardian_decision == PASS- state: DESIGN_DEFINING         ← 状态2：设计定义                           agent: design_agent                                                        condition: product_run_status == SUCCEEDED                               - state: ARCH_DEFINING           ← 状态3：架构定义                           agent: arch_agent                                                          condition: design_run_status == SUCCEEDED                                - state: SCV_GATE                ← 状态4：数据约束提取                       agent: orchestrator_agent                                                  condition: arch_run_status == SUCCEEDED                                  - state: SPEC_REVIEWING          ← 状态5：执行规格评审                       agent: evaluator_agent                                                     condition: arch_run_status == SUCCEEDED                                  - state: CONTRACT_DRAFTING       ← 状态6：合同起草                           agent: arch_agent                                                          condition: arch_run_status == SUCCEEDED                                  - state: TESTCASE_DESIGNING      ← 状态7：测试用例设计                       agent: testcase_agent                                                      condition: contract_status == ACTIVE   

3.1.2 如何解决上下文文污染和爆炸的问题

planner和builder的拆分

planner和builder在单智能体做的职责太多，会导致上下文爆炸，尤其是在长任务当中，任务非常多，会导致上下文爆炸。

解决方案：planner拆分为product, design, arch, builder拆分为testcase和builder

按照实际开发当中的职责分别去委托到不同的Agent当中，并且拆分彼此的上下文，进而避免上下文爆炸导致的生成质量下降的问题。

1. Planner 拆分为 3 个专业 Agent

2. Builder 拆分为 2 个专业 Agent

每个Agent做完一次任务，下次要启动新的subAgent

1. 启动新的SubAgent是为了避免上下文污染，在执行长任务的过程当中，随着轮次的增加，如果不开新的上下文会导致生成的速度和质量都会下降。

2. 强制每次生成SubAgent和独立验证有助于避免上下文污染的问题，从我们的实验来说当一个agent在同一个上下文开启多件事情的时候，记忆会混乱，实现质量快速下降。

3.1.3 如何解决解决评估独立性问题

builder和planner本身不能自己做所有事情，我们在上一步已经按照功能点对builder和planner做了拆解。Evaluator也应该跟着一起做拆解，才能保证评估的独立性，同时也能避免Evaluator评估维度过多，导致彼此干扰。

contract_reviewer、proposal_reviewer、impl_reviewer、frontend_design_reviewer、testcase_reviewer、prd_reviewer。每个子代理有自己的 prompt、技能模块和评分标准，能单独接受 Benchmark 评估，单独迭代。

拆分后必须强制执行三条设计原则：

• 评审与生成彻底分离：同一个 AI 既写又审行不通——它给自己打满分太容易了。Evaluator只输出反馈，不改代码。

• 零信任：Builder 说”测试通过了”，Evaluator得自己跑一遍测试。Builder 说”服务已启动”，得自己验证。没亲自验证过的声明，一律当不存在。

• 零 Broken Feature：Evaluator是最后一道防线，不能因为”只差一点点”就放水。

3.1.4 如何实现Agent的进化

当Evaluator评估Agent本身问题之后，会有一些Agent经常犯的错误，需要针对这些错误优化各自的Agent的Prompt，或接入一些针对性的skill来帮助减少类似问题的发生，实现在执行过程当中避免重复犯错，进而实现自进化的目的。

我们常见的几个问题：

1. builder卡点卡的不严格，导致应该执行的某些规则，未被正常执行。

2. design  agent声明了6个设计维度，但是实际执行的时候丢失了某些设计维度，导致设计的维度实现不全。

3. arch agent在执行架构设计的的时候没有执行superpower的skill，导致了设计质量的下降。

这些都需要不断的观测，迭代，在循环当中不断修正，进而实现Agent的自我进化。

想要实现Agent持续的自进化，就需要Evaluator不断找出问题，那么Evaluator自身的评估能力的好坏直接决定了后续迭代的走向。因为Evaluator已经是最后一个卡口了，但是怎么知道Evaluator的能力强不强？到底是60分位还是90分位？这就需要单独建设评审能力评估体系。

3.2.1 核心结论

Evaluator的“评审能力”这个抽象概念，可以被拆开，变成可以测量的指标。 通过下面的两个步骤来完成可度量的设计。

• Benchmark 设计：评估的不是代码质量，而是Evaluator评得准不准。用代码片段和完整项目两类样本，覆盖静态分析和动态验证两种模式，多维度打分。

• 优化闭环：每次评估完拿评审报告和标准答案对比，找到薄弱环节，针对性优化后再测，实现评审能力提升不靠感觉，靠数据。

3.2.2 Benchmark 的本质：评估的是评审能力，不是代码质量

Benchmark 做的是”元评估”——评的不是代码写得好不好，而是Evaluator评得准不准。这个区别很关键。

1. 给Evaluator一份植入了 bug 的代码，它只找出一部分，说明检出能力不够。

2. 反过来，给一份零 bug 的高质量代码，它硬挑出一堆问题，说明太挑剔。这两种情况都是评审能力有问题。

impl-reviewer（代码实现评审）是第一个建立 Benchmark 的，优先对impl-reviewer建立benchMark的原因是：

1. 它的评审对象最容易量化。代码要么编译通过，要么报错；测试要么通过，要么失败。相比之下，评审 PRD 或设计稿，主观判断的成分更大。

2. 相关的开源数据集更丰富，也更容易构建权威的数据集，更客观的去评估impl-evaluator的评估代码的能力。

impl-reviewer主要负责校验代码写的对不对，是否能通过E2E测试保障功能正常，因此我们的考察维度是几个维度：

1. 每个文件内的代码写的对不对，是不是能过代码审核

2. 整个项目是不是能跑起来，项目当中的BUG是否能够被正常识别。

3. E2E的测试Case是不是能跑通

3.2.3 BenchMark数据集怎么构建

impl-reviewer 要评估的是 builder 产出的代码合不合格——功能完不完整、架构合不合理、代码规不规范。这几项里，“代码规不规范”和”功能完不完整”最好量化，”架构合不合理”主观判断多。所以 Benchmark 围绕前两项做，分两个层次。

第一层：code snippets用来评测代码质量评估能力。

1. 针对“代码规不规范”做了code snippets, 同时设计了good example和bad example，同时我们也准备了正确的答案，用不同的文件夹做了隔离。

2. 我尝试从 GitHub 权威开源项目里挑优秀代码片段和典型问题代码做基准数据。

3. 使用Golden Answer 标注了每处违规的级别、对应的 ESLint 规则编号、修复方案。

4. 我们在评估时看 impl-reviewer 能检出多少违规、误报了多少好代码、严重程度判定准不准。

第二层：project 项目质量评估能力。

1. 我们针对“功能完不完整”,做了project级别的good example和bad example，同理我们也准备了正确的答案，也用不同的文件夹做了隔离，为了保证真正能测试出Agent的能力，因此我们选了三种不同复杂度的完整项目，通过梯次设计复杂的项目来预防Agent能力过强，导致没有区分能力无法体现。我们选取的项目是todo项目（简单），博客（中等），电商（复杂）。

2. 我们在负面组按 OWASP Top 10、CWE 通用缺陷列表等权威标准来做问题的植入。

a. 项目植入了不同等级的 bug 和漏洞，涵盖并发安全、注入攻击、越权访问、敏感信息泄露等类型，同时我们也保证了BUG的数量，方式数量过少导致没有区分能力。

b. 在打分的时候我们针对不同等级的BUG的打分也分了级别，针对简单难度问题1分，中等难度的问题2分，复杂困难的问题3分，通过区分不同难度，匹配分数，能更好的反应我们的Agent在项目级别当中的问题。

3. 我们对这些 bug 在源代码里不做任何注释，零提示状态，完全模拟真实评审——评测的是”发现问题的能力”，不是”读取注释的能力”。

3.2.4 评审流程：三层评估 + 快速失败优先

评审员的工作分三个层次，由浅入深，每一层都有明确的检查项、验证工具和退出条件：

这三层对应评审深度的递进：第一层看代码写得规不规范，第二层看架构设计得合不合理，第三层看功能跑得对不对。

为什么必须分层？ 因为每一层的成本和置信度不同。静态分析几秒钟就能跑完，成本极低；动态验证需要启动服务器、跑浏览器测试，成本高。如果第一层就挂了，没必要花几分钟跑第三层——这就是”快速失败”的核心逻辑。

快速失败优先：具体执行流程

评审流程遵循快速失败优先原则，按以下顺序执行，任何一步失败即终止，不跑后续步骤：

Step 1: 环境变量检查（< 1 秒）  ├─ 检查 .env.local 是否存在  ├─ 检查必要的环境变量是否已配置（如数据库连接串、API Key）  └─ 失败 → 退回 Builder，提示"环境未配置"Step 2: 依赖安装检查（5-10 秒）  ├─ 检查 node_modules 是否存在  ├─ 检查 package.json 中的依赖是否已安装  └─ 失败 → 退回 Builder，提示"依赖未安装"Step 3: 编译验证（10-30 秒）  ├─ 运行 TypeScript 编译（tsc --noEmit）  ├─ 检查是否有类型错误  └─ 失败 → 立即终止，输出类型错误清单Step 4: 开发服务器启动（15-30 秒）  ├─ 启动开发服务器（npm run dev）  ├─ 等待服务就绪（curl localhost:3000 返回 200）  └─ 失败 → 退回 Builder，提示"服务无法启动"Step 5: 静态分析（30-60 秒）  ├─ 运行 ESLint 检查  ├─ 扫描安全违规（如 localStorage 使用、SQL 拼接）  └─ 失败 → 输出违规清单，终止评审Step 6: 动态验证（2-5 分钟）  ├─ 运行 Playwright E2E 测试  ├─ 检查浏览器控制台无 JavaScript 报错  ├─ 验证第三方 SDK（如地图组件）正常初始化  └─ 失败 → 输出失败测试清单，终止评审

道理很简单——环境没配好、服务起不来，花十几分钟跑完整评审就是浪费计算资源。快速失败检查能在 1 分钟内拦住 80% 以上明显不合格的实现，把计算资源留给真正值得深度评审的提交。

实战案例：快速失败的价值

第一次实战中，Builder 提交了一个路书功能的实现。评审员按传统方式跑了完整流程：安装依赖（30 秒）→ 编译（20 秒）→ 启动服务器（15 秒）→ 跑 E2E 测试（3 分钟）。结果发现 E2E 测试 215 个失败，评审耗时接近 4 分钟。

问题出在哪里？回看发现，Builder 根本没配置 .env.local，数据库连接失败，所有测试自然全挂。如果按快速失败流程，Step 1 环境变量检查 1 秒就能拦住，节省了近 4 分钟的计算资源。

第二次实战引入快速失败后，同样的场景下，评审员在 Step 1 就发现 .env.local 不存在，直接退回 Builder，整个评审耗时从 4 分钟降到 1 秒。Builder 修复后重新提交，评审员才进入后续的动态验证步骤。

核心信念：宁可让Evaluator花 10 次 1 秒钟快速退回，也不允许 1 次 4 分钟的无效评审。

3.2.5 评分体系：两个模式去做独立评分

独立评分的目的是观测Agent到底是单纯代码写的不好，还是项目当中的问题识别不了，更加精确的定位问题，方便后续的迭代。Benchmark 根据样本类型用不同的评分体系，归一化到满分 100 分。

代码片段模式（code_snippet）：纯静态分析，评估代码规范识别能力。四个维度：

1. 规则遵从率（40分）看找全了没有

2. 严重度加权分（30分）看分级分对了没有

3. 一致性得分（20分）看规则分类准不准

4. 报告质量（10分）看能不能指导修复。

完整项目模式（full_runtime）：静态分析加动态验证，满分 100 分。

1. 静态分析占 40 分（Bug 检出率 15 分、精确度 10 分、安全审计 10 分、结论校准度 5 分）

2. 动态验证占 60 分（测试验证 20 分、构建验证 15 分、运行时验证 15 分、性能验证 10 分）。

最终得分还要乘以能力系数——如果Evaluator没跑测试、没做构建、没启动服务，能力系数会打折，确保”纸上谈兵”拿不到高分。

3.2.6 优化闭环：用数据驱动持续改进

有了评分体系之后，评审能力高低终于有了客观标尺。但 Benchmark 的价值不只是打个分——它真正有用的是让持续优化形成了一个闭环：跑评估 → 对答案 → 找弱点 → 改提示词 → 再跑评估。三轮下来，均分从 64.5 提到了 83.4（+18.9），精确匹配率从 25% 拉到了 78%，评分偏差从 +59 收窄到 -3。

3.2.7 这个闭环是怎么转起来的

每次评估完，系统会拿评审报告和标准答案逐项对比，找出哪里弱了就针对性改。改完再跑一遍 Benchmark，分数上去了才算真的提升了。这个闭环不是一次性的，是一直在转。评审能力提升不靠感觉，靠数据说话。

3.2.8 三轮优化过程

第一轮：Baseline 评测（均分 64.5）

刚跑的时候问题就暴露出来了，三个核心问题：

第二轮：系统性重构（均分 67.5，+3）

找到根因后，针对性地做了三件事：建统一的代码质量评分体系、强制自评输出代码质量分、把结论判定和标准答案强制对齐。效果直接体现在分数上：

第三轮：全面修复退化项（均分 83.4，+15.9，通过阈值）

第二轮分数上去了但仍未通过（67.5 < 75），细拆发现退化项抵消了优化成果：CRITICAL 漏检 2 个、负面误报从 ~0 暴增到 ~12 个、级别误判从 2 增加到 3。第三轮针对性地做了三件事：建立 CRITICAL 强制检查清单消除漏检、引入误报白名单校验机制。效果显著：

三轮总览：

三轮跑下来验证了一件事：问题定位靠数据对比，改进方向靠根因分析，效果验证靠分数复测。这个闭环会一直转下去，直到评审能力达到目标水位。

a. 构建一个本地和云端都都能顺滑运行的环境，有助于快速的提升生成的效果。 构建环境时，本地与云端常存在差异（如 Node 版本、依赖解析等）。我们曾遇到本地开发正常、但云端构建失败的情况。因此，统一并工具化本地与云端环境，是保障 AI 生成与测试顺滑的关键。

b. 环境是包括但是不限于SDK，底层的框架，业务沉淀的业务层工具，业务自己沉淀的组件等等，我们遇到过builder Agent宣称自己开发完了加签算法，但是根本无法通过，于是我们封装好了加签算法，告诉builder项目结构，就能调用的很好。

2. 环境工具化会导致开发环境就是一种约束，通过限制在特定场景下使用特定的组件或工具，能更快速的让AI理解你的业务，更好的写出符合你的业务要求的代码。

评审报告需要包含 CRITICAL/MAJOR/MINOR 分类

a. 根据不同的问题的严重程度依次修复，更容易提升效率

b. 在检测的时候，如果evaluator已经识别出了阻塞性问题，可以直接反馈给builder，避免不必要的token浪费，可以直接跳过后续的测试case的执行。

这部分的难度被严重低估了——很多人觉得”AI 能力到位了，串起来就行”，实际上”串起来”本身就是巨大的工程量。

1. 各环节串联中的具体问题：

• 第一个坑是状态管理。每个 Agent 执行完毕后，系统需要准确判断：它是成功了还是失败了？如果是部分成功怎么办？它产出的结果是否满足下游的输入要求？这些判断逻辑远比想象中复杂。

• 第二个坑是超时和资源管理。Agent 调用大模型是有延迟的，一个复杂任务的单次 Agent 执行可能需要几十秒甚至几分钟。把五六个 Agent 串联起来，再加上门禁检查和可能的重试，一个完整任务的耗时可能长达十几分钟甚至更久。你需要考虑超时策略等一系列问题。

• 第三个坑是环境一致性。代码 Agent 生成的代码需要在真实环境中验证，这就涉及到构建环境的准备、依赖的安装、测试环境的隔离。任何一个环节出问题，整条流水线就断了。

• 第四个是我们在串联的时候往往不是一遍就成功的，在失败过程当中，我们需要知道每次失败发生在哪里了，什么时间发生的，为什么发生，这种可追溯的日志系统在工程设计上也是必要的，但是往往这是人们所忽视的，有了这些可追溯的日志，才能保证你的问题能被发现和解决。

2. 仍然需要保留手动线上部署

自动部署上线看起来是最简单的一步，但是实际做起来才发现，部署前的预检查、部署后的健康检查、灰度发布的策略、回滚的触发条件……每一个都是独立的工程问题，而且一旦上线之后，再回滚都是损失，所以目前我们在部署线上环境（日常环境全自动）这一步仍然保留了人工确认环节，用人来保证上线前的卡点，尽管人不能保证100%没问题，但人不是依赖概率的，而是真实的执行全流程，真实的去和业务同学去交互和确认的，这些仍然是AI所暂时无法替代的。

完全无人干预不是一个 0/1 的状态，我们认为现阶段真正有价值的不是追求 100% 的无人化，而是把人工干预的频率和成本降到足够低——低到一个人可以同时”监护”几十个并行运行的任务，只在少数需要判断的关键节点介入。这其实正是 OPC 场景下这套系统的价值所在：不是替代人，而是把一个人的产能放大到原来的几十倍。

不要追求一步到位的全自动化，这是不现实的，甚至每次循环只解决一个Agent的某个点的问题。当你上来就想一次性实现端到端跑完，问题会从各个环节同时涌出。每个版本尽量保证最起码的通路，然后再当前版本上迭代下一个版本，这种方式会让你在每一步都拥有清晰的基线——上一轮验证过的部分是可信的（实在不行还能回滚到上一次嘛），新问题一定出在这一轮新加的部分。

长链路的稳定性仍然脆弱。从发现机会到代码上线，经过 8-10 个节点，即使每个节点的成功率是 90%，端到端的一次通过率也可能会因为过程中的各种原因导致失败。目前靠重试机制和门禁回退来兜底，但是基本上不可能一次性写完之后，就100%符合要求，基本上还是要1-3次不等的循环才能把P0的问题修掉。

目前我们这个系统还是阶段性探索未主要目标，当前进展效果的质量还没有完全达到高标准的要求，还需要持续在系统工程化上做很多优化才能达到我们真正预期的效果。但随着模型的进步，我们现在所面临的各种问题都会被内化解决掉，离我们的愿景就越来越近。

这是当前制约系统质量的一个深层问题——门禁体系的有效性取决于”元评估”的能力，也就是”裁判员的裁决本身够不够准”。目前的评估标准主要靠人工经验制定，覆盖度不够：PRD 门禁对某些边缘场景的需求缺乏判断依据，样式门禁对非标准布局的评估标准模糊。

1. 目前覆盖了项目和代码片段的级别，但是对于Product，Design, Arch, testCase这些Agent,缺少开源的数据集，构建数据集难度较大，持续自建数据集，有助于提升这些环节的评估的“元能力”。

2. 针对无开源数据集的Agent,想要持续门禁的”元评估”能力，需要自建数据集，自行标注数据集。构建bad case和good case，以及标注标准答案。

总的来说，这套系统探索的不只是一个技术方案，更是一种工作模式的可能性：一个人加上一组训练有素的 AI Agent，能否交付过去需要一个小团队才能完成的工作？

从目前的实践来看，答案是”在特定领域，已经可以了”。PC网站这个场景的特点是：模型擅长、实现明确、反馈周期短、试错成本低。这些特征让它成为 AI 自主系统的理想试验田。但更多的领域——特别是那些决策后果严重、反馈周期长、需要深度领域知识、安全合规极高的场景——还需要更成熟的 Harness 框架才能安全地让 Agent 介入。但可以明确的是未来 OPC 模式的上限会随着 AI 能力的提升而持续放大。

本文转载自阿里云开发者，原文链接

https://mp.weixin.qq.com/s/sZm-KDM7NoITchuhpbJkJQ