阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
一、做这个系统的背景
故事的起点是我们持续在围绕高德地图PC站做SEO优化，在探索各个方向上能带来增长的可能。偶然在某社媒上看到一个内容是关于一个人怎么利用AI自主发现需求并全程自主开发和上线APP的并能自动进入下一个提案的探索与执行。立马在我们的脑子中开始火星撞地球，决定在PC站SEO这个场景下借鉴这个思路，并且实践OPC（一人公司）。
发现增长机会、设计方案、编写代码、测试上线这条完整的链路上，每个环节都需要专业能力和大量时间。传统的做法每个链路都需要有特定的人来参与或者先进一点是人工指挥多个AI工具来完成，但在 OPC 的思想下，AI Agent独立自主完成是可以有机会实现的一个路径。
业务尝试
因此我们尝试贯彻“一人公司”的设计理念，开始思考如何让 AI 自主发现网站的增长机会，自主生成提案，自主完成从需求文档到代码实现再到部署上线的全流程，中间加上合规风险监测，并且全程不需要人工干预？更进一步，这个系统能否周期性地重复这一过程，持续探索和迭代？
先说结论结合我们的业务目标，我们基于Harness Engineering实现了这套业务流程图
为了验证系统的稳定性，我们前期先以"路书"功能为核心例子（旅行路线规划工具）进行验证。从输入提案，系统自主开始 PRD 编写到发布到日常环境，全程 0 人为介入，连续运行4小时, 实现路书应用，主流程无P0 Bug。
二、系统怎么做
2.1 经典Harness Engineering
Harness Engineering是指围绕 AI Agent（特别是 Coding Agent）设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。
它解决的核心问题是：当 AI Agent 拥有了强大的代码生成能力后，如何确保其输出的可靠性、一致性和长期可维护性。
我们来看anthropic实践是如何落地的：
构造Planner智能体，它接收简短的 1-4 句提示，并将其扩展为完整的产品规格说明。
构造Generator智能体，Generator首先根据用户提示创建一个 HTML/CSS/JS 前端。
构造Evaluator配备了 Playwright MCP，使其能够在对每个标准评分并撰写详细评语之前，直接与运行中的页面进行交互。在实际操作中，Evaluator会自主浏览页面，对页面进行截图并仔细研究实现效果，然后再给出评估结论。
这些反馈随后作为下一轮迭代的输入，回传给Generator。
2.2 实际落地的业务架构
经典的Harness Engineering在让 AI 能够自主完成复杂任务，不再是一次性问答，通过反馈循环保证质量，在Harness Engineering思想之下，我们的自主增长系统需要更加细分的设计来贴合业务诉求：
需要总控的Agent负责统筹和调度
需要记忆系统和来记录执行过程和传递输入输出，记忆系统共享知识，上游产出自动成为下游输入
需要拆分Agent，保持专业的人做专业的事，每个 Agent 专注自己擅长的领域
需要增加专业skill，来在垂类方向上更加的准确，节约时间。
三、多Agent架构落地方案
3.1 如何保障架构落地
在实际的架构落地过程当中我们仍然要解决几个问题：
3.1.1 如何保障长任务的正常运行整个生成项目的任务被定义成一个workflow， 通过状态机定义流程 + 子 Agent 分工 + 反馈循环迭代 + 独立评审门禁，来解决长任务的问题。
1. orchestrator负责监听和派发任务状态，同时在memory系统当中，以文件的形式记录运行的日志和流转过程。
a. memory的分解表格
一级分类
目录
子目录结构
用途
定义产物
prds/, designs/, architectures/, contracts/, artifacts/
无子目录，平铺文件
存放 workflow 各阶段产出（PRD、设计、架构、契约）
评审记录
evaluations/
按评审类型 → 按 Sprint → 按轮次
存放评审报告 + E2E 证据（截图、日志）
Agent 运行记录
runs/
按 Agent → 按 Task/Sprint
存放 Agent 生命周期状态（.started → report.md → .completed）
决策记录
decisions/
平铺文件
存放 orchestrator 派发决策
2. orchestrator保证任务正常执行的机制：
a.心跳监控：子 Agent 在RUNNING状态时需定期发送心跳，否则可能被误判为超时。
b.状态流转：任务需依次经历DISPATCHED→ACKED→RUNNING→SUCCEEDED/FAILED。
阶段
状态标记
描述说明
任务派发
DISPATCHED
总包工头将任务派发给子 Agent
子 Agent 确认接收
ACKED
子 Agent 确认收到任务，标记为ACKED
任务执行中
RUNNING
子 Agent 开始执行任务，定期发送心跳（如每 60 秒）
任务完成/失败
SUCCEEDED/FAILED
子 Agent 完成任务后标记为SUCCEEDED（成功）或FAILED（失败）
c.超时恢复：TIMED_OUT或STALLED任务需人工或自动触发重试机制。
超时类型
条件
状态标记
处理逻辑
确认超时
子 Agent 300 秒内未发送ACK
TIMED_OUT
任务标记为TIMED_OUT，需重新派发或人工干预
执行超时
子 Agent 1200 秒内未完成任务
STALLED
任务标记为STALLED，停止执行或触发失败处理
轮询检查
-
-
每 60 秒检查一次所有任务状态，触发超时判定
下面是一个轮询配置
child_run_protocol: ack_timeout_seconds:300 #5分钟没确认 → 超时 default_stall_timeout_seconds:1200#20分钟没进展 → 卡死 orchestrator_poll_interval_seconds:60 # 每60秒检查一次 3. 每个Agent都有明确的进入条件（condition），执行这个步骤前必须满足的前提，防止跳过必要环节、保证流程顺序正确 。
steps:-
本文网址：
