一个 Agent 连续工作接近 9 个小时，听起来自主执行能力已经很强了。
但如果这 9 个小时里，它一直在错误的方向上努力呢？
9 月 12 日，在 PEC 2026 AI 创新者大会暨第三届提示工程峰会的 Harness 工作坊上，知名 OPC、TRAE Expert 彭超讲起了自己一次“被 AI 坑了”的经历。
一个准备充分的 Coding 任务，最初几天跑得很顺。随着人工检查逐渐减少，Agent 开始长时间自主执行，任务断断续续做了两个星期，最长一次连续运行接近 9 个小时。
问题慢慢出现了。
上下文越来越长，模型开始在细枝末节里来回修改，最后进入彭超所说的“上下文腐烂”。
今天的 Agent 已经越来越会干活。真正困难的，开始从“它能不能做”，变成“怎样让它在一个真实任务里把事情做成”。
三个小时里，几位一线开发者从个人 Coding、Agent 底层原理、企业工作流、Skill 演进一直谈到模型评测，把 Harness 背后那些通常不会出现在 Demo 视频里的问题通通搬到了现场。
第一步，先让Agent明确什么算“完成”
彭超把自己总结的工作方法概括为 GCC：Goal、Context、Constraints。
其中，Goal 回答的是“什么才算完成”。
给 Agent 一个任务，不能只说“做个系统”或者“把材料整理一下”。最终交什么、达到什么标准、什么时候应该停止，都需要提前明确。
Context 回答的是“依据什么行动”。
原始材料从何而来、何时获得，哪些是已确认的事实，哪些是过往的判断，哪些仍只是假设，都需要区分清楚。否则，上下文越堆越多，Agent 能看到的材料越来越丰富，却未必知道什么值得相信。
Constraints 则是任务的边界。
权限、预算、时间，哪些事情可以自主决定，哪些节点必须回来找人确认，都属于 Constraints。
三者合在一起，便构成了一份人在任务启动前与 Agent 达成的“工作约定”。
这也是彭超反复强调的一点：执行可以越来越多地交给 AI，但任务负责人仍然是人。当 Agent 能连续自主工作几个小时甚至更久，人不必守在旁边替它完成每一步，但必须把目标、依据和边界握在手里。
Harness 在这里发挥的作用，也不是让 Agent 跑得更远，而是让它知道在哪里跑、什么时候停，以及跑偏之后如何回来。
有了 Loop，模型才真正开始自己决定“下一步干什么”
任务约定清楚之后，才进入执行。
词元映射 CTO 梁凯锐从最基础的代码讲起，现场演示了一个 Agent 是如何一步步搭建起来的。
最开始演示的是普通的模型调用：用户提出问题，模型给出答案。加上工具以后，模型便能去查日期、查日程。
比如用户提出的是一项旅行安排，程序可能需要先确定日期，再查询日程，然后预订机票和酒店。每走一步，都会产生新的信息，也需要重新判断下一步该做什么。
这时，一个持续运行的 Agent Loop 出现了。
模型观察当前信息，决定下一步调用哪个工具。程序执行工具，把结果重新交给模型。模型再根据新的结果继续判断，如此循环，直到任务结束。
在这个循环中，“下一步做什么”的一部分决策，从预先写死的程序逻辑，转移给 Agent 本身。随后，System Prompt、工具、Skill、上下文不断加入，一套 Agent 系统才逐渐成形。
这套机制下，当出现问题时，让我们能够知道该去哪里找原因。到底是模型能力不够，是上下文出了问题，是工具调用有误，还是程序本身的逻辑需要调整？
Agent 越能自主行动，这种判断反而越重要。
Agent 进企业后，先到具体岗位“上岗”
Agent 特区创始人、知名 FDE 马工分享了一个制造业案例，把前面这些方法落进了真实业务。
这家制造企业很早就想用 AI，但和不少公司一样，真到动手时，反而不知道从哪儿开始。
买 GPU？建 AI 中台？还是先培训员工？
马工团队没有先做一套覆盖整个公司的大系统，而是找到一条核心业务流程，让 Agent 像一个新员工一样先到具体岗位“上岗”。
他们最终进入工程研发部门，和企业里最有经验的工程师一起，把原本存在于个人经验里的工作方法整理成 SOP。
接下来再判断：哪些事可以交给 Agent，哪些还得人来做。
客户沟通、关键判断、最终验收，仍然由人负责；资料收集、启动仿真软件、盯着长时间计算这类执行工作，则交给 Agent。固定 Workflow 用来卡住一些关键步骤，防止 Agent 一次判断失误就直接跳过去。
马工提到，上线后有个仿真任务怎么都跑不通。
好在输入、执行过程和结果都留了记录，团队一路往回查，最后发现不是 Agent 的问题，而是客户一开始给的一项风扇参数错了。
参数修正以后，任务终于跑通。随后团队在工作流里新增了一道参数检查，下次再遇到类似任务，系统就会提前把这个问题拦下来。
一次失败，不只是被解决掉就结束，还变成了流程的一部分。
两个多月后，一些过去只存在于资深工程师脑子里的经验，开始沉淀进 SOP 和 Agent。
这也是理解 Harness 很直观的一个例子：不是要造一个无所不能的 AI 员工，而是把真实工作里的步骤、判断、边界，甚至失败，慢慢变成一套能重复运行的系统。
Skill 不是越多越好，工作流不能太复杂
个人开发者云舒分享了自己过去一年工作方式的变化。
最初是用 Prompt。当时模型能力有限，人需要写很长的 PRD，不断提供上下文。
后来 Skill 流行起来。写 PRD、做 UI、发版、Debug，不同工作都可以被封装成 Skill。云舒自己的 Skill 一度积累到四五十个。
很快，新问题又来了。Skill 多了以后，也会互相“打架”。
规则越来越多，模型同时需要处理的上下文越来越复杂，与当前任务无关的 Skill 甚至可能被误触发。
于是，他又开始做减法。关闭不需要的 Skill ，把一些原本分散的环节合并进更完整的 Workflow，让 Agent 自己完成更多调度。
这个变化背后还有一个现实：模型本身一直在进步，昨天为了补模型能力不足而设计的一套复杂流程，几个月之后，可能反而会限制模型。
所以 Harness 也不是搭好一次就结束。人需要不断重新判断：哪些工作今天已经可以交给模型，哪些地方仍然值得保留人工判断。
在云舒现在的 Coding 流程里，人更多负责需求讨论、关键方案确认和最终验收。开发、测试、Code Review 等大量执行工作尽可能由模型承担，不同模型甚至可以彼此 Review。
但如果一个简单任务也要经过多个 Agent、多轮审核、长时间运行，Token 和时间成本同样会迅速增加。
工作流的目标，从来不是“看起来足够复杂”。说到底，是把事情做完，并且做得值得。
什么结果才算好，必须提前想清楚
当开发、测试甚至 Review 都开始交给模型之后，一个问题会越来越突出，怎么知道它真的做对了？
云舒把评测集称为生产级 Agent 最难解决的问题之一。
如果团队自己都说不清“什么结果算好”，那么后面无论怎样更换模型、增加 Skill、调整工作流，都很难知道系统究竟有没有变得更好。
AI 雷达（大模型智商众测）社区创始人、分布式雷达发起者陈昱的分享，进一步把这个问题放到了真实运行环境里。
他认为，静态排行榜越来越难完整回答开发者每天真正遇到的问题。同样的模型、同样的 Harness、同样的任务，今天和明天的表现都可能发生变化。模型版本会调整，服务负载会变化，真实调用环境也并不固定。
因此，AI 雷达尝试用“真人、真机、真任务”的方式持续测试。开发者在自己的机器上运行任务，记录 Agent 的执行轨迹，再统一评估结果。
比较的校准也不再是一道题的对错，任务完成率、时间、成本、Token 消耗，都开始成为判断一套 Harness 是否真正好用的指标。
毕竟在真实工作里，用户真正在意的并不是什么 Benchmark 分数，而是这个任务能不能按要求完成，要花多少钱，又是否能够稳定地复现。
Harness，其实是一套工作方法
从这几场分享里可以看出，Harness 其实并不是一个单独的软件框架，它可能是一份任务开始前的 GCC，是驱动 Agent 连续行动的 Loop，是企业里的 SOP 和 Workflow，是权限、预算和停止条件，也是一次任务结束后的评测记录，甚至是一次失败之后，新增加的一道参数检查。
当Agent 越来越会干活之后，人的位置发生了变化。过去，由人亲自完成大量步骤，现在，人越来越多的时间会花在定义任务、设计流程、设置边界、判断结果，以及把一次次成功和失败沉淀成下一次可以复用的工作方法上，从而让Agent 做事，越来越可控、可验、可复现。
