前两年大家还在争论“AI能不能写代码”，我现在的担忧已经变成另一件事：AI太能写了，写出来的东西根本没人看管得住。我见过一个团队，某次迭代里让AI帮着改一个支付模块，结果它一口气改了二十几个文件，连带把无关的日志格式、变量命名全部翻新了一遍。代码review的时候没人能说清这些改动是怎么来的、模型的判断依据是什么、中途有没有中途换过思路，最后只能全部回滚重来。这种情况发生得多了，你就会意识到：AI Coding的问题从来不是“写得不够好”，而是过程不可控、结果不可复现、行为不可审计。
我在这件事上折腾了半年多，最后沉淀下来一套做法——Agentic Harness Workflow 框架。简单说，就是不再把AI当成一个“你问我答”的对话工具，而是把它塞进一条有阶段、有门禁、有审批、有审计的工程流水线里。它做的不是让AI更聪明，而是让AI的每一次代码修改都像正式提交一样，有任务描述、有上下文边界、有质量检查、有回滚预案。这篇文章就把这套框架的设计思路、落地步骤和我在实践中踩过的坑完整写出来，给正在把AI Coding往团队级推的人一个参考。内容会偏实操，涉及任务拆解、上下文管理、门禁设计、调优参数和故障排查，不写空理论。
1. 为什么要把AI Coding塞进“流程”里
1.1 我踩过的AI Coding烂摊子
先讲几个真实发生过的情况，如果你也在用AI写代码，大概率不陌生。
第一件事发生在某次功能迭代。我们的需求是给用户中心加一个“最近登录设备管理”。某同事直接开了个对话，让AI改。模型很积极，把controller、service、mapper、数据库脚本、前端页面全部生成了一遍。结果合并的时候发现，它把单例模式的Bean改成了原型模式，理由是“登录设备列表可能需要频繁创建实例”。从编译角度完全没问题，但从系统设计角度这是一个完全没有必要的破坏性改动。更麻烦的是，这件事是在上线前一天的code review里才被发现的，因为代码生成时没有任何东西会强制AI解释“为什么这么改”。
第二件事更典型。某个AI辅助生成的模块，第一版生成得很顺利，功能和单测全部通过。但到了第三轮迭代，模型需要理解之前的上下文，它居然把上一版里已经修好的一个边界条件又改回去了，而且没有任何提示。因为对话窗口太长，模型自己都忘了前面改过什么。这种“间歇性失忆”在人工写代码时几乎不可能出现，因为人只要翻了git log就一目了然；但AI不会主动去看，也没有任何机制强制它去看。
第三件事是协作问题。现在很多模型都能直接改本地文件，但当一个仓库里同时有三个人各自开着AI对话时，就乱套了。AI A改了公共工具类，AI B同时也在改同一个文件，两边都认为自己是“最新状态”。最后merge的时候冲突爆炸，谁也说不清哪个版本是对的。这种问题本质上不是模型能力问题，而是缺乏统一的编排层——没有哪一层在管“当前仓库的状态是什么”“AI能不能动这个文件”“它动的依据是什么”。
这三件事给了我同一个结论：AI Coding真正缺的不是工具，是流程。
1.2 工程化要解决的四个核心问题
在对AI Coding做了几个月观察之后，我把痛点收敛成四个，这也是Agentic Harness Workflow框架要解决的核心问题，每个都有对应的工程手段，后面会展开讲。
可复现性。同样一个需求描述，今天让AI改和明天让AI改，出来的代码可能完全不一样。这在探索阶段没问题，但在交付阶段就是灾难。工程化的做法是把需求变成结构化的任务卡，把仓库状态、模型版本、上下文范围、约束条件全部固化下来，让一次执行变成一条可回放的记录。
可控性。传统开发里，“改动任何一行代码”背后都有人的判断。AI没有这个判断，它只是按概率补全。所以必须给AI划定明确的活动边界：哪些目录可以动、哪些文件只能读、哪些操作必须经过人工确认、测试不通过能不能提交。这不是限制AI，而是保护代码库。
可协作性。当多个AI任务同时跑在一个仓库里，必须有一个机制管理文件锁、变更范围和提交顺序，否则必然冲突。这个机制不属于模型，属于工作流框架。
可度量性。人力写代码可以靠review度量质量，AI写代码不行——没人有精力一行行审查AI生成的两千行代码。所以要有自动化的质量门禁，用测试、静态检查、覆盖率、变更统计来兜底。
这四个问题，恰好都是工程问题。AI是执行单元，而框架负责让执行单元在正确的时间、以正确的范围、按正确的标准去干活。
2. Agentic Harness Workflow 框架的整体设计
2.1 核心理念：不是“指挥AI”，而是“约束AI”
我接触到的大多数人，对AI Coding的第一反应是：我给它一个任务，它帮我把代码写出来，这就是AI Coding。这种思路是“以AI为中心”，人围着模型转。而Agentic Harness Workflow框架是反过来的：以流程为中心，AI只是流水线上的一个执行节点。它在那里负责提笔写代码，但真正决定写什么、写到哪、怎么验收的，是流水线本身。
打个比方，传统的AI Coding像是你雇了一个很聪明但资历很浅的实习生，给他一个需求，他自己决定怎么干；而Agentic Harness Workflow，是把这个实习生放进一个有标准作业程序的生产线，每个工位都有明确的操作手册、质量标准和签字确认环节。工作流框架是生产线的骨架，AI是线上最勤奋的那个工人。这条生产线要确保一件事：无论今天来的工人是谁（GPT、Claude、还是某个开源模型），产出的质量都保持在一个基准线上。
这就是Harness这个词的含义——一套把模型“套住”的约束系统。它不提升模型智力，它保证即便模型智力波动，流程还能兜底。
2.2 框架的五层管线拆解
我在设计的时候，把整个工作流拆成了五个阶段，对应一次AI Coding任务从进到出的完整生命周期：
任务受理层（Intake）。这一层判断“这个任务适不适合AI做”。不是所有需求都适合丢给AI，不合适的不接。适合的任务会被转成标准化的任务卡，包含目标、验收标准、文件范围、可用工具、风险等级等信息。任务卡是整个流水线的“订单”。
上下文组装层（Context Assembly）。这一层负责收集AI需要知道的一切信息：仓库结构、相关模块代码、git历史、既有测试、技术规范、相关issue。最关键的是对所有信息做“预算管理”——上下文窗口是有限的，必须决定哪些内容必须看，哪些内容可以压缩，哪些内容根本不看。这一步直接决定AI后续输出质量。
执行循环层（Execution Loop）。这一层是AI真正写代码的地方。但它的执行不是一次性的，而是“计划—编写—测试—修正”的循环，循环到所有门禁通过或者明确失败为止。执行循环里又包含工具调用，比如ls、grep、读文件、改文件、跑测试。所有工具调用都要经过权限过滤。
质量门禁层（Quality Gate）。这一层是检查站。AI完成任务后，不会直接提交，而是先跑静态扫描、单元测试、代码规范检查、变更影响分析。门禁不通过，打回重新修改；门禁通过，进入下一层。
发布与审计层（Release & Audit）。这一层处理最终产物：生成commit信息、创建MR/PR、附加AI执行报告（包括模型版本、上下文摘要、变更文件列表、质量门禁结果）。更重要的是把整个执行过程记录下来，形成日志，方便事后溯源。
这五层不是可选项，它们是“工程化”这四个字的最小实现。少任何一层，都会退化回“AI自己写代码”的原始状态。
2.3 从对话式到工作流式的三个关键改变
刚开始把AI Coding工程化的时候，最容易踩的坑是“把对话记录当流程记录”。你确实可以把聊天记录导出成文档做审计，但这有个本质问题：对话式执行没有“阶段边界”。AI可能在一段对话里从“修复bug”漂移到“重构整个模块”，用户自己也未必能察觉。工作流式的执行，最关键的是做了三个改变：
第一个改变是把隐性过程变成显性状态机。对话式执行里，AI的内部推理过程对用户是不透明的；工作流式执行里，任务从受理到发布，每一步都有明确的状态：排队中、上下文收集完毕、计划生成、执行中、门禁测试、等待人工审批、已发布。每个状态都有清晰的进入条件和退出条件，任何一步卡住都有明确提示。
第二个改变是把无限操作变成有限操作。对话式执行中，AI可以做任何事——读取任何文件、修改任何文件、执行任何命令。工作流式执行里，我通过权限策略限制了AI的工具面：只读范围、可写范围、需审批范围、完全禁止范围。比如生产环境配置文件，AI永远只能在审批通过后由工作流框架代为修改，AI自己拿不到写入权限。
第三个改变是把一次性输出变成可迭代交付。对话式执行里，AI给你一份代码，你拿回去自己测试，出问题再回来问它。工作流式执行里，测试是内嵌在流程里的，AI的模式是“写一段—跑测试—根据结果调整—再跑测试”，直到测试通过或者明确告知失败原因。这个循环是框架控制的，不是在一句话里碰运气。
3. 落地实操：搭一条能跑的AI Coding流水线
3.1 第一步：用统一任务卡把需求“格式化”
整个框架的门槛在任务卡。如果任务卡写得含糊，后面所有环节都会跟着糊。我自己的实践是把任务卡做成JSON结构，而不是自然语言描述。原因是JSON字段是强约束的，AI能理解，机器也能校验它内容是否完整。
以下是我实际在用的任务卡模板，有所简化但保留了核心字段：
{ "task_id": "TASK-2025-001", "title": "用户中心增加最近登录设备管理", "type": "feature", "priority": "P1", "entry_conditions": { "base_branch": "main", "required_context_files": [ "backend/src/main/java/com/example/user/UserController.java", "backend/src/main/java/com/example/user/domain/LoginDevice.java", "backend/src/main/resources/db/migration/V20250101__create_login_device.sql" ], "context_budgets": { "total_tokens": 60000, "file_weight": "read_new", "max_files": 20 } }, "scope": { "allowed_dirs": ["backend/src/main", "backend/src/test", "frontend/src"], "read_only_dirs": ["backend/src/main/resources"], "forbidden_dirs": ["deploy/", "docs/private/"] }, "acceptance_criteria": [ "支持查询最近10条登录设备记录", "支持移除指定设备", "所有变更通过eslint和spotless校验", "新增单元测试覆盖率不低于80%" ], "quality_gates": ["build", "unit_test", "static_analysis", "coverage_check"], "approval_required": ["db_migration", "api_contract_change"] }写任务卡时有几条心得。第一，required_context_files字段必须精确到文件，不能写“你去看一下用户模块”，AI会猜，而猜错的代价是整个代码库的污染。第二，scope字段是防御性的，宁可严一点也不要松，AI天生倾向于“多改一点更保险”，这个字段就是拦住它的缰绳。第三，验收标准要写得“机器可判”，避免“体验流畅”“性能好”这类模糊描述，门禁层是要拿这些条件做自动核验的。
任务卡格式统一之后还有个额外好处：它可以做回归测试。同一张任务卡，换个模型跑一遍，或者隔一周再跑一遍，我就能比较两次输出的差异，量化看出不同模型风格漂移有多大。
3.2 第二步：上下文组装与预算控制
任务卡准备好了，接下来是把AI写代码需要的参考材料喂给它。这一步看起来简单，其实是整个框架里翻车率最高的地方。核心矛盾是：模型上下文窗口有限，但一个真实的业务仓库很大，随便扫一遍都可能超过几万个token。
我用的方法分两步。第一步是静态文件收集，直接按照任务卡里的required_context_files抓取文件内容，再做一次token估算，控制在总预算的60%以内。第二步是动态探索，允许AI在限定范围内去搜索它认为相关的文件，但每探索一个文件都要消耗预算。所有探索操作都走框架的代理，不能直接读仓库。
以一个真实任务为例：任务要求“给订单模块增加导出功能”，预算分配大概是这样：
- 任务卡与需求描述：约2000 token
- 硬性相关文件（订单实体、订单查询服务、控制器）约15000 token
- 动态探索配额：约10000 token
- 预留上下文空间：约30000 token
我吃过亏的地方在于给模型预留上下文太满。曾经把一个4万token容量的大模型塞满到95%，结果模型在生成长代码时出现“截断式输出”——写到一半就开始重复前面的话，或者直接编写了一个看起来结尾但逻辑未完的模块。后来我把执行时的上下文占用率控制在75%到80%之间，情况才稳定下来。所谓预留空间不是浪费，它是给模型输出留的“手写区域”。
另外，我不建议一次性把所有文件内容塞进去然后让AI“自己挑重点”。模型确实具备一定筛选能力，但它筛错时你很难发现。更好的做法是分层喂：先给它任务卡，让它自己列一个“我需要的文件清单”，再由框架根据清单拉内容。这个步骤叫“计划征询”，看似多了一轮交互，实际减少了大量无效token消耗。
3.3 第三步：执行循环里的门禁设计和工具权限
当上下文准备完毕，框架会启动正式的执行循环。我设计循环的状态机大概是这样的，每个阶段都有明确的进入和退出条件：
计划阶段。AI先生成一份简要实现说明，说明它准备怎么改、涉及哪些文件、有无风险。这个说明不需要详细到每行代码，但必须让审查者能看出方向对不对。如果计划与验收标准明显不符，直接终止任务并反馈给用户，不浪费执行阶段的钱。
编码阶段。AI按计划修改文件，但它并不能像原生编辑器那样任意操作，所有文件读写都要经过工作流框架的“工具层”。工具层做的事只有三件：检查路径是否在允许范围内、记录操作前后的文件哈希、统计当前变更的规模（比如新增行数、删除行数）。
验证阶段。框架自动运行质量门禁脚本。我用的是四条线：编译构建、单测、覆盖率检查、变更错误率。这个“变更错误率”是我自己定义的指标——AI删除的代码行数里，有多少行是原本有单测覆盖的。如果AI删掉了被测试覆盖的逻辑，即使测试暂时能过，也说明它动到了核心逻辑，应该给人工检查加分。
门禁不过的时候，AI并不会无脑重试。框架会把失败的测试输出原样喂回给模型，模型分析失败原因，提出修改方案，再进入编码阶段。这里有个细节值得说：我给AI的失败反馈是结构化的，而不是一串日志。比如“build失败，原因：缺少导入的类OrderStatus；位置：OrderExportService.java:42；建议排查：检查第38行是否引用了未导入的枚举”。直接给错误日志原文大模型也能看，但结构化信息能显著减少它瞎猜的概率。
工具权限的设计也需要单独说。我把文件目录划分为三个等级：可读写、只读、禁止访问。可读写目录一般是业务代码目录，只读目录一般是配置文件、生成脚本，禁止目录一般是密钥目录、部署环境目录、既有文档。这种划分必须落在框架层，而不能靠“提示词让AI自觉遵守”——AI不是不听话，它是记不住自己说过的话，所以要在环境层面禁止。
3.4 第四步：人工审批节点插在哪
我一直强调一个观点：AI Coding做不了完全无人值守。至少现阶段不做。但哪些地方需要人盯，哪些地方可以放手，是可以精确配置的。在我的框架里，人工审批节点一共有三种类型，各有触发条件。
第一种是变更类型审批。任务卡里的approval_required字段写明了哪些类型的变更必须等人点头。比如数据库迁移脚本，AI把脚本生成好没问题，但真正允许执行这个脚本、提交这个文件，必须人来确认。另一种是API契约变更，AI把接口签名改了，这会影响调用方，不能自说自话。
第二种是变更规模预警。AI的直观倾向是多改。如果一次任务修改的文件数超过任务卡预设的上限，或者单文件新增行数超过了一个阈值，框架会自动挂起，走人工确认。这个阈值我一般设置成“单文件新增超过300行”或“核心文件超过3个”——超过这个量，说明AI可能跑偏了。
第三种是上下文断裂审批。这是AI特有的问题。模型在长任务执行过程中，可能因为token超限而丢掉早期信息，导致后续修改方向出现漂移。框架会监控执行循环里的“计划一致性”，如果发现AI的行为偏离了它在计划阶段自己写的描述，就会停下来问审核人：方向变了，继续还是回退。
你可能会问，审批节点这么多，效率会不会很低？我的实测结果是，设置合理的审批规则后，大约七成任务可以全程无人干预直接跑完，剩下三成触发审批的任务，绝大多数确实是应该拦下来看一眼的。审批节点存在的意义不是拖慢流程，而是把人的注意力集中在最需要判断力的地方。
4. 让工作流真正好用的调优细节
4.1 Token预算的分配逻辑
Token是所有AI Coding工作流里最硬的约束，很多框架跑不好不是因为模型不行，是预算分配出了问题。我自己的分配经验，大致遵循一个比例：计划阶段15%，探索阶段25%，执行阶段50%，验证阶段10%。
为什么计划阶段只给15%？因为计划阶段如果占太多，模型就容易进入“过度分析”，输出一大堆策略、方案、考虑事项，但没有什么产出。执行阶段给50%，是因为它有真实的活要干，需要完整的上下文窗口。验证阶段虽然只给10%，但要注意这个阶段主要消耗的是测试输出的回填，不是模型的长文本输出，所以量不大。
还有一个很重要的点：每个阶段结束时要清理“思维草稿”。模型在思考过程中会产生大量中间文字，比如“我决定先这样再那样”，这些内容对后续阶段没有价值，但占据上下文窗口。框架在每个阶段结束时会做一次摘要压缩，把AI的“内心独白”替换成一段结构化的执行摘要。这个操作能节省大约20%的token消耗，同时降低后续阶段被无关信息干扰的概率。
4.2 模型选择与重试策略
不是所有任务都适合同一个模型。我平时的做法是，在框架里配置了一个“模型路由表”，不同类型的任务选择不同的基础能力：
- 简单bug修复、机械重构：优先选择单次推理成本低、执行速度快的模型
- 复杂多文件功能开发：选择指令遵循能力更强、长上下文稳定的模型
- 数据库脚本、生成型内容：选择代码生成质量高的模型，并强制开启“保守模式”（减少创造性输出）
模型路由的关键不是比谁的“考试分数高”，而是匹配任务类型。曾经有个任务，用最强模型跑出来了太多“惊喜”——它自己觉得格式统一化更好，把整个模块的代码风格做了一轮全量修改。换了一个更强调整体一致性的中等规模模型之后，这个问题反而消失了。所以在我的框架里，任务卡里其实还藏着一个字段：model_preference，不做复杂度判断时，由路由表决定用哪个模型。
重试策略也必须设限。模型第一次跑不过门禁，可以重试，但重试次数一般不超过三次。更重要的一点是：三次不通过不是再试第四次，而是降级处理。降级方式是换模型重跑，或者把任务拆成更小的子任务。我见过有人让同一个模型重试十次，花费了大量预算，结果模型只是换一种方式重复同样的错误。模型的自修复能力远没有我们想象中强，给它太多机会只是浪费钱。
4.3 并行任务与仓库冲突管理
当框架真正投入团队使用，并行是绕不开的话题。多个AI任务同时跑在一个仓库上，要避免互相踩脚。我的方案是在框架层实现一个轻量级的“文件锁服务”。每个任务执行前，框架扫描该任务涉及的文件范围，跟正在运行的任务做比对，如果有重叠，就排队等待，等到锁释放了再启动。
文件锁粒度需要控制。太粗（比如锁整个仓库）会严重降低并行度，太细（锁到类级别）又会让锁管理本身成为瓶颈。我自己实践下来，锁到目录级是性价比最高的：同一个业务模块下的任务串行执行，不同模块可并行。这个粒度既不频繁冲突，也足够安全。
还有一种冲突是“逻辑冲突”——文件不重叠，但业务逻辑关联。比如任务A改了订单状态枚举的某个值，任务B在另一个服务里开发一个依赖这个枚举的新功能。文件层面看不出来，但代码集成时必然炸。这个问题的解决不靠锁，靠的是任务卡阶段的人工分派：如果两个任务都涉及同一个核心业务域，就不该同时下放给两个AI任务执行。
4.4 缓存与增量执行
AI Coding工作流跑多了之后，你会发现有很多重复劳动。同一个模块，上次已经让AI分析过结构，这次又要分析一遍。为了不重复烧钱，我给框架加了个“中间产物缓存层”。AI探索时读取过的文件内容、计划阶段生成的模块摘要、已经执行过的测试结果，都会带签名缓存起来，只要仓库版本没变，直接复用。
这个机制能省多少时间？我跑过一组对比：某次任务第一次执行花了大概八分钟，其中大部分时间消耗在上下文收集和代码探索上。同一天内再给同一模块下发一个关联任务，因为缓存命中，整个上下文组装过程只用了不到一分钟，直接进入编码执行阶段。对于迭代密集的团队，这个优化带来的收益非常明显。
缓存需要注意一个坑：必须监控仓库更新事件，一旦文件有变更，相应缓存要立刻失效。我曾经忘记处理这个，导致第二次任务用的是旧版代码的摘要，AI基于过期信息写出来的补丁完全对不上新代码的逻辑，白白浪费了一次执行。现在我把缓存失效逻辑挂到了git hook上，只要仓库有新的commit，相关路径的缓存全部清空，宁缺毋滥。
5. 常见问题与排查技巧实录
5.1 上下文溢出导致的“失忆式改代码”
症状：任务跑到一半，AI开始重复前面的操作，或者修改一个之前已经明确说“不改”的文件，仿佛完全忘记了前面的对话。
原因：上下文窗口溢出，早期关键信息被挤出去了。
排查方式：看执行日志里的token占用曲线，如果在执行阶段出现断崖式下降或压缩摘要频繁发生，基本可以确认是这个原因。
我的处理办法有三个。第一，缩小任务卡范围——一个任务如果涉及超过20个文件，就拆成两个任务。第二，强制启用“阶段摘要”，也就是在每个阶段结束时，让框架把AI的执行历史压缩成结构化摘要，而不是保留全部原文。第三，调整context_budgets里的预留比例，把预留空间从20%提高到25%-30%。如果以上三个都做了还是溢出，问题大概率出在任务卡的设计，而不是框架，得回头重新拆分需求。
5.2 AI陷入“执拗循环”怎么办
症状：同一个单元测试反复失败，AI每次都说“找到了原因，正在修复”，但修改之后测试依然不过，循环三四轮。
原因：模型陷入了某种思维定势，它基于自己之前生成的错误代码反复推理，无法跳出来看问题。
排查方式：看连续几次执行循环里的“失败原因描述”是否几乎一样。如果AI每次给的原因描述雷同，说明它不是在真正排查，而是在重复碰运气。
这类问题的有效解法是中断式反馈。具体做法是：当连续两次失败原因高度相似时，不再把失败信息直接喂回模型，而是由框架中断当前循环，给它注入一段外部观察信息，比如“用户在日志中注意到初始化顺序有问题，建议查看配置类的加载顺序”。这等于给模型提供了一个额外的“外部记忆”，帮它跳出思维定势。实测下，这个方法能解决七八成“循环修不好”的问题。
5.3 质量门禁的“伪通过”现象
这是最危险的一种问题，因为它骗过了所有自动检查。具体表现是：AI执行的代码完全通过了单测和静态检查，但它改坏了另一个模块的功能——而那个模块的测试没有被本轮触发，所以门禁是绿的。
排查思路：门禁只测了它改过代码覆盖的范围，没测“它间接影响的范围”。所以我在框架里增加了一个步骤：变更影响分析。在门禁通过后，框架会扫描变更文件列表，结合代码依赖图，自动识别出所有“依赖被修改文件”的上游模块，再把这些上游模块的测试也拉出来跑一轮。虽然多花一点时间，但能拦住大部分跨界破坏。
5.4 并行任务的提交时序冲突
症状：两个任务各自通过门禁，AI先后生成两个commit，但第二个commit基于的是第一个commit之前的仓库状态，导致分支合并后代码互相覆盖。
原因：并行执行的任务，在生成补丁时都对同一仓库状态做了基线，但提交顺序有先后，后提交的补丁覆盖了先提交的同期改动。
排查方式：看提交记录里的parent commit，如果它们不是线性的关系，说明基线漂移了。
解决方式是给提交阶段加一个“基线检查”：提交前，框架比较当前仓库HEAD和任务执行时的基线版本，如果存在不同，先自动rebase目标代码，再重新跑一次增量测试。整个过程对AI是无感的，但对仓库安全至关重要。刚跑这套流水线的时候我没加这个步骤，吃过两次不小的亏，后来就再也不敢省了。
6. 我的最终体会与扩展建议
把这套框架从想法变成能稳定跑的东西，花了我大概两个月的时间。最开始的日子非常难受，工作流比直接用AI对话麻烦很多，跑一个简单功能要设置任务卡、跑门禁、检查日志，一顿操作猛如虎，一看产出就一点。但我当时给自己定了个规矩：坚持用这个“麻烦”的流程跑完一整个迭代，再评估它是否值得保留。结果是：第三周开始，麻烦感明显下降，因为任务卡有了模板库，常用的目录权限和门禁配置都是现成的；团队协作的顺畅度提升非常明显，至少再也没有出现“某个文件被同事的AI改了但没人知情”的事故。
如果你也想在你的团队推进这件事，我的建议是不要一步到位。先挑一个低风险的模块，跑通一条最小工作流，把任务卡、上下文组装、一条门禁和人工审批这四件事做好，就已经胜过市面上大部分“AI自由发挥”的用法。等团队适应了这种节奏，再逐步接入缓存、并行锁、路由表这些进阶能力。
从更大的视角看，Agentic Harness Workflow这类框架，本质上是在为AI时代的软件工程建立新的“施工规范”。就像当年从手工写代码走向集成开发环境、从线下部署走向持续集成一样，AI不会取代工程师，但“谁能让AI在工程约束下稳定工作”，谁就能在同样的人力和时间里交付多几倍的功能。这套东西我还会继续迭代，下一步想把执行日志做成人机都易读懂的结构化数据，让每一次AI修改都能像正式工程文件一样被检索、对比和复盘。
