我想趁自己还记得，把这些记下来。将来如果有人翻到这里，正要动手建一个 agent------希望这些经验，能让你少走一些我走过的弯路。
一、很多 agent 活不到第三十天
先说我看到的现象。
我见过的很多 agent 活不到第三十天。而且它们死的方式出奇地安静：没有崩溃，没有事故，它甚至还能用------只是从某一天起，没有人愿意再打开它。
往回倒带，这些 agent 有着非常相似的一生。头几天，它以 demo 或者一两个功能的形式被造出来，做点小事，完成得还行，所有人都挺满意。但不知道从哪一天起，它的能力就再也追不上人们的期待：它做成了一件小事，人们就开始设想它能替人完成十件；它跑通了一个环节，人们就开始指望它跑通全程。到第三十天，落在它身上的，已经是端到端跑完一整套复杂工作的期待。
在整个过程中，agent 并非完全没有变强。人们也会给它补功能、改提示词、换工具。但能力是一点一点地补，期待却是一倍一倍地涨------它永远活在自己够不着的期待里。到最后，真正让人放弃它的，不是某次崩溃，而是一次次「达不到期待」累积起来的失望。
「期待落差」是真的，但它更像一个间接原因，不足以定生死。定生死的变量，藏在别的地方。我决定回到它出生的那天，重新查一遍。
二、它是照着「想象中的工作」造出来的
回到 agent 出生的现场，我注意到一个决定 agent 生死的因素。安全科学里有一对概念，叫 work-as-imagined 和 work-as-done------想象中的工作，和实际发生的工作。用大白话说：一项工作在需求、流程和制度中被设想成怎样完成，与执行者面对具体情境时实际采取哪些做法把它完成，往往存在差异。
而中途夭折的 agent，几乎都踩过前者的坑。
我见过的情况，大致有两种。
一种情况是，设计者在为别人做 agent。真正的工作长在执行者手里，是活的，也一直在变化；但写需求、画流程的时候，执行者往往不在设计现场。负责拆解任务的人，只能凭自己的理解、经验，或者几场访谈，去还原这项工作是怎样完成的。到了纸面上，原本充满例外和临时判断的工作，往往会被整理成一条静态、干净、前后连贯的流程------它更接近「想象中的工作」，而不是「真实发生的工作」。
另一种情况更隐蔽：设计者在为自己做 agent。此时，设计者就是执行者，按理说应该最清楚工作是怎样完成的。但真正坐下来设计 agent 时，很多人并不会先把手头的工作完整地跑一遍，观察每一步究竟卡在哪里，又有哪些环节一直在依靠没有被说出来的判断。相反，他们会跳过这一步，直接凭经验画出一张「应该如此」的流程图，再照着这张图把 agent 写出来。
这两种路径最终汇到同一个动作上：设计者把根据经验或想象还原出来的流程写成文字，再交给 AI，通过 vibe coding 把 agent 搭出来。设计者以为自己记录了工作；实际上，记录下来的只是头脑中那张经过整理的画面。
问题不在于真实的工作不存在，而在于它很难被完整地带到设计现场。前一种情况下，关键细节留在执行者手里；后一种情况下，关键判断藏在那些早已习以为常的动作里。等工作被写成流程，这些没有被观察、没有被说出的部分都会消失，剩下的是一套看起来合理、实际上并不完整的描述。agent 从出生起，拿到的就只是这个被压缩过的版本。
第一天它表现得不错，可能只是因为 demo 验证的，恰好是已经被写进流程的那部分工作。到了第三十天，真实现场里的例外、上下文和临场判断一个接一个地出现，那些在设计时被压缩掉的部分，才开始暴露出来。
三、真实工作的摩擦，没有变成 agent 的经验
出生那天留下的缺口，并没有当场判它死刑。进入真实工作后的二十几天里，它本来还有机会一点点补上。
真实的工作每天都会把纸上遗漏的部分翻出来：没料到的例外、写漏的细节，跑完才意识到「那一步不该这么走」的懊悔。每一处偏差，都可能把它往真实拉近一点。
但这需要两个条件同时成立：它得活得够久，让问题浮出来；问题浮出来之后，人还得真的把它放回去。
现实里，这两个条件很少同时成立。有时甚至一个都不占。
有些 agent 是为一个项目临时搭出来的。用了几次，项目结束，方向一换，它也就停了。不是没用，是活得太短。那些足以暴露缺口的例外和毛边还没来得及浮现，故事已经翻篇。它甚至没能走到被真实修正的那一步。
另一种情况是，agent 活得够久。天天在流程里跑，问题也一个接一个地往外冒。
只是，问题虽然出现了，经验却没有跟着长出来。
输出错了，人顺手改一下；卡住了，人绕过去；接不住的，人兜个底。它没崩，人也不觉得麻烦。可每一次顺手，都截断了一次本该回到它身上的反馈。
反馈停在了人手里。这次出的问题，没人记下来；错在哪一步、为什么错，没人拆开看过；怎么走才对，也没有写进任何能影响它下一次运行的地方。
对眼前的工作来说，问题已经解决了。对 agent 来说，记录、归因、修正------三个阶段，一个都没有发生。
时间在往前走，它却停在原地。等到下周二，同样的问题再来一遍，它还是照原来的方式挂掉，人也还是照原来的方式替它扛。
它天天泡在真实的工作里，却没有从摩擦中长出能力------因为每一次摩擦，都有人替它承受了。
它不是被用坏的，是被护坏的。
四、陪 agent 长大，成了另一份全职工作
护住它，并不意味着代价消失了。它没有接住的那部分真实，最后都落在了人身上。
每次 agent 出问题，人面前都有两条路：一条是自己接过来，把眼前的工作做完；另一条是停下来，记下问题，拆开原因，修改它，再重新跑一遍。绝大多数时候，前一条都更简单。不是兜底不费力，而是教会它要费更多力。
所以，人一次次做了当下最合理的选择：先把事情做完。
可每一次选择自己接手，也就意味着这一次的经验仍然停在人身上。agent 没有因此多会一点，下一次走到这里，人还得重新接过来。
我后来才意识到，人以为自己只是在偶尔替它兜底，其实人早已成了这套流程里一个没有被标出来的固定节点。它不会的那部分，并没有随着任务完成而消失，只是被长期留给了站在它身后的那个人。
而这，其实是一份工作。一份没有被写进任何职责、也没有人认领的工作。
它甚至不只是通常所说的「维护」。维护默认面对的是一个已经成形的东西；陪 agent 长大，面对的却是一个还没有成形的东西。人不仅要把眼前的问题处理掉，还要把每一次兜底留下来、拆开来，变成它下一次可以使用的东西。处理问题，让今天的工作继续往前走；留下经验，才让明天的同一个问题不再需要人亲自接住。
这份工作的成本，有时并不比从头搭出一个 agent 低多少。因为搭出它，可能只是把纸上的流程变成一套能跑的东西；带着它长大，却要把真实世界里不断冒出来的例外，一点点补回它身上。
这件事没有清晰的边界，也没有哪一天可以彻底宣布完成。你得把变化的现场喂给它，把它缺失的上下文一次次补回来；它判断错了，你要标注、归因、纠正，再让它重跑。它每往前走一步，都可能踩进一个新的坑，你就得再扶一次。
「它会慢慢变好」------这六个字真正意味着的是：得有人陪它走过变好的过程。
而这张账单，没有明确由谁来付。
所以我慢慢相信，一个 agent 能活下来，往往不只是因为它的架构有多好，还因为它背后站着一个非常有耐心的人。这个人愿意把自己的判断力一遍遍借给它；愿意在它犯错的时候，不绕开，也不放弃；愿意陪它从只能跑通纸上的流程，走到可以独立应付真实的现场。
agent 的成长，不只是一行代码的事。它需要一个人的耐心，反复地、持续地、常常不被记账地投进去。
但这样的人太少了。
大多数时候，agent 被搭出来，用过几次，遇到一些问题，人也就撤了。不是懒，是真的扛不住。陪一个 agent 长大，太像另一份全职工作。而大多数人，连第一份都已经够累了。
五、harness：让支撑不再随人离开
案子查到这里，几乎成了一个死局：agent 要长大，就得有人长期陪着它；而这份工作没有人认领，也很少有人真正付得起。也正是这个死局，让我一下子看懂了 harness 的意义。
这个词的本义是「挽具」：套在马身上的那套结构。马还是那匹马，但有了它，力气才能真正拉动车。在 agent 的世界里，它指的是围绕 agent 搭起来的一整套支撑系统。此前我只把它当成工程上的配套设施。直到追到这里，我才意识到，它回答的正是那个问题：怎样把压在一个人身上的持续兜底，变成一套不会随着人离开而消失的东西。
harness 不替 agent 做判断，也替代不了那个陪它长大的人。它做的是一件更基础的事：把那些原本需要人随时记得、随手补上、一直盯着的部分，变成系统可以自己持续运转的事。
在此之前，一个 agent 是靠在人身上的。人理解现场，人记住上下文，人发现它哪里出了错，也由人决定下一步怎么办。这些全都零散地压在一个人的注意力上。人一走，支撑就跟着消失。harness 接走的，就是其中不必非人来做的那部分。
一条持续供给的管道，让变化的现场自己流进来，不用再等人搬运；一层记忆，让工作的来龙去脉留得住，不用每天重过第一天；一些核查点，标出它的判断该在哪里停下来、交回给人。不再靠人一直盯着，那条原本断在人手里的链------记录、归因、修正------第一次有了自己接续的可能。
这是 harness 能接走的全部。但它接不走的，是另一层东西。
那不是信息搬运，也不是记住流程，而是一种判断力：十条信息摆在面前，哪一条才真正要紧；这一次和上一次看着一样，差别藏在哪里；数据还没显出异常，人却已经先觉得不对劲。这样的判断，从来没有被完整写进流程，也很难提前沉淀进系统或知识库。过去，它和搬运、记忆、盯守混在一起，看起来只是一堆琐碎的人力活。等 harness 把琐碎接走，才看得清楚：人一直往里放的，是那些没法预先写下来、只能在现场成立的东西。
harness 留不住判断力本身，但能留住每一次判断的痕迹：当时注意到了什么，为什么觉得它重要，事后结果如何。判断力依然长在人身上，只是不再耗在搬运和盯守上，而是只在真正需要的时候出手；而每一次出手都被记下来，慢慢攒成它将来也许用得上的案例。
当劳动被交还给系统，人的那一部分，才真正显现出来。
到这里，开头那个疑案也可以补一句结论了。期待落差解释了人为什么离开，却没解释 agent 为什么一直追不上。现在答案齐了：它追不上，是因为真实工作给它的反馈从来没有留下来过；而它要活下去，还得有人把那部分没法写进系统的判断，一次次补进去。
六、有了 harness，人能退场吗？
harness 接走了搬运、记忆和盯守，把人的判断力从杂活里单独留了出来。
但判断力留下来以后，人还是得坐在那里，一次次往 agent 里补东西。所以，harness 搭好之后，人究竟能退到哪里？
答案取决于三条不同的边界。
1. 能力边界------人能退，但账很贵
围棋 AI 已经证明，在边界清楚、反馈明确的任务里，判断力可以长进系统，人可以退出每一次具体判断。
但这需要付两笔账。
一笔是训练。系统需要大量真实、专项、带有反馈的案例，每一次输赢、偏差和修正都要留下来。
另一笔是 codify。人一眼就懂的边界条件，要被拆成规则；人顺手绕过的坑，要被写进流程；人凭直觉察觉的异常，要找到可以识别的信号。那些藏在「我反正知道」里的东西，都得被翻出来，重新表达，直到系统也能走过去。
这两笔账原理上都能付，只是远比大多数人预想的昂贵。很多 agent 仍然离不开人，不是因为这条路走不通，而是因为账还没有付完。
2. 责任边界------创造者能走，责任人不能缺
大多数真正跑起来的 agent，停在这里。
它依赖的是通用的审慎：有没有遗漏，结果是否可靠，关键点有没有覆盖。这些判断不属于某个特定的人。我可以离开，另一个认真负责的人接上，系统照样运转，它还是它。
但判断可以换人，责任不能悬空。
agent 出了错，必须有一个具体的人承担后果、解释原因、决定下一步怎么办。它可以离开创造者，却不能取消「有人负责」这个位置。
这不是缺陷，而是结构。
3. 身份边界------换了人，它还是不是它
还有一类判断，很难完整交接。它与「好不好」无关，与「谁在判断」有关。
哪条线索值得继续追，哪些微弱的信号需要被放大，哪里可能藏着还没有成形的问题------这些取舍不完全是对错问题，更是取向问题。
这就像一个品牌更换主设计师。供应链、团队和流程都还在，做出来的东西却会慢慢发生变化。不是变差了，而是变成了另一种东西。那些取舍很少被写进手册，却决定了作品最终「是不是它」。
依赖这类判断的 agent，在创造者离开以后仍然可以运行，只是它会逐渐变成另一个 agent。
所以，「人能不能退场」没有一个统一的答案。
能力上的依赖，是一笔尚未付完的账：训练和 codify 做得足够深，人就能继续往后退。
责任上的依赖，是一个不能空缺的位置：创造者可以离开，但必须有人接住结果。
身份上的依赖，则来自无法无损迁移的取向。它既是一种依赖，也是创造者留在 agent 身上的痕迹。不能急着把它当成债消除，也不能只把它当成勋章。
因此，一个 agent 仍然离不开你，并不足以说明它只是一个半成品。真正需要分清的是：它在等一笔尚未付完的账，需要一个不能撤掉的责任人，还是已经和你的某些判断取向长在了一起。
我把这个也记下来。
知道这些，并不会让陪一个 agent 长大变得更轻松。但至少，人终于能够看清自己为什么还站在那里：是在替系统还债，替结果负责，还是在守住一种换了人就会改变的东西。