夜雨聆风几天前，一位IT圈的朋友看了我写的《啥是md文件？》那篇文章，给我提了个思考题："你可以试着研究一下，AI工作体系下，怎么给Agent评价绩效？"
这个题把我难住了。抠了几天脑壳，还是不知道怎么解。
于是去查资料。花了几天翻了十几篇，技术圈的、学术圈的、咨询圈的都在聊这个话题。专业性、前沿性都挺好，但有一个共同的问题：大词太多。Task、Trial、Trajectory、pass@k、HITL……别说没技术背景的HR和企业老板，我一个计算机科班出身的人，第一遍读也脑壳疼。
我就想，能不能换一种讲法——从IT、OD、Advisor三个视角，试着把这件事说清楚。
先说几个可能让你犯晕的词
Agent：不是"更聪明的ChatGPT"。ChatGPT是你问它答，Agent是你交代一个任务，它自己想办法完成——查资料、调工具、做判断、出结果。你可以把它理解成一个能独立干活的数字员工。
OD（组织发展）：不是玄学。OD就管三件事——组织该长什么样、人跟岗位怎么匹配、人跟人怎么协作。AI时代多了一件事：Agent跟人、Agent跟Agent怎么协作。
企业系统工程：一种看问题的方式——不盯着单个环节，盯整个链条。Agent没干好，不一定是Agent自己的问题，可能是工具不行、数据有问题、或者用的人不知道怎么用。系统思维就是"出了问题先查环境，再查当事人"。
Advisor（顾问）：站在企业外面往里看的人。好处是能看到内部看不到的东西，坏处是只看不干，最终干活还得企业自己的人。
好，翻译完了。
IT视角：技术圈怎么评，以及一个更重要的提醒
技术圈讨论Agent评估，核心框架可以概括成三件事：
第一，先定义清楚要干什么。 你说"帮我处理客户邮件"，太模糊了。你得说"把客户邮件分成三类——投诉的转给客服主管、询价的回复标准报价单、其他的归档——准确率不低于90%"。这跟HR写岗位说明书是一模一样的逻辑：岗位职责不能模模糊糊。
第二，同一件事跑N遍，看稳不稳定。 这里面有个HR听了会心一笑的概念：叫"pass@k"和"pass^k"。前者是说跑k次有一次成功就行，测的是能力上限，相当于面试表现。后者是说跑k次次次都得对，测的是可靠性底线，相当于日常工作表现。你招人的时候两种都看，评Agent也是。
第三，不看结果看过程。 Agent每一步干了什么、用了什么工具、为什么选A不选B，全部有日志。这是管人时做梦都想要的东西——人的工作过程是黑箱，Agent的工作过程是全透明的。
谁来评？三种方式：有标准答案的，直接写规则自动判——相当于客观题自动批改；没标准答案的，用另一个AI来评——相当于同行评议；高风险场景，人亲自审——相当于专家评审。三种方式各有漏洞，但叠在一起，漏洞就对不上了。这跟HR做绩效评估的路数一模一样：不能只靠一个人的打分，要多来源交叉验证。
以上是基本框架。但在讲"怎么评"之前，我觉得有一个更重要的提醒。
大部分场景不需要Agent。
Agent不是"更聪明的ChatGPT"。它增加复杂度、延迟和成本。如果你的任务规则清晰、不需要多步推理和判断，传统自动化就够了。先想清楚该不该用Agent，再想怎么评。
查资料的时候看到一个数据让我印象很深：顶尖AI模型做复杂Agent任务，成功率只有大约30%。30%是什么概念？你部署一个Agent，十次里有七次可能搞不定。如果你没有评估机制就把它放到生产环境，等于闭眼开车。
我拿自己做了个实验
写这篇文章的时候，我做了一件有意思的事：用同样的题目，让两个不同的Agent帮我写初稿。 一个叫Claw，一个就是现在帮你整理这些文字的这位。
实验条件不太一样。Claw是先上场的——我给了它一个比较模糊的题目，它自己琢磨，写出了一个版本。我看完之后觉得不行，推翻重来，又翻了大量参考资料、梳理了方法论框架，然后把明确的需求和参考资料给了第二位Agent。
结果呢？
如果只看产出——Claw写的初稿比较像一本操作手册，结构工整，表格清楚，信息密度高，但就是不太像一篇"给人看的文章"。第二位Agent写的更有故事感、更有"人味"、更像专栏该有的样子。
按照一般人的直觉，结论很简单：Claw不行，换掉。
但这是错的。
我后来认真想了一下：Claw接的是第一版模糊需求，没有参考资料，第一个上场没有任何"前人踩过的坑"可以参考。第二位Agent接的是经过两轮失败后想清楚的精准需求，有11篇精读笔记做知识库，还有一个完整的方法论框架当脚手架。
如果我只比产出，不比环境——那我就是在犯绩效评价最经典的错误：把系统的问题归到个人头上。
换到企业场景里，这个错误天天在发生。Agent不好用？换模型。换了还不好用？再换。从来没有人去查：提示词写清楚了吗？工具权限给够了吗？知识库更新了吗？上游数据质量行不行？用的人知道怎么用它吗？
大部分"Agent不好用"的问题，根源不在Agent本身。
这就是技术圈在讲的"评的不是Agent一个人，是Agent+工具+环境整个系统"。用大白话说：出了事先查环境，再查当事人。
OD视角：Agent就是一个岗位
读资料的时候，有一句话直接打中了我："AI Agent不是工具，是新型劳动力。"
如果Agent是劳动力，那它就不是IT系统——它是一个"员工"。只不过这个员工不领工资、不吃午饭、不会请假。
一旦接受这个前提，HR的整套方法论就有了用武之地。
Agent本质上就是一个组织岗位：它有职责（写在系统提示词里），有工具权限，有协作关系（跟人配合、跟其他Agent配合），有考核标准。它接收输入、加工处理、产出输出、接受评估——跟一个人类岗位没有本质区别。
那OD在干什么？OD就是在管"谁干什么、跟谁配合、怎么考核"。以前"谁"指的是人，现在多了一类"员工"叫Agent。
这里我想分享一个真实的体会。
几年前，我参与了一家科研企业的咨询项目。咨询团队负责数字化转型规划，从战略到流程，再到各业务的信息系统，全部做了详细设计。企业本身也有一定信息化基础，PLM、ERP等系统都初步建立了。
但企业领导觉得，数字化转型最大的障碍不是系统不够好，是：现有的信息系统都没用起来，新的规划怎么能够用起来？
我当时从人力资源和组织发展的角度提了一些建议：摸清员工实际工作中使用信息系统的真实情况，打通部门间的信息系统协同，建立跨部门信息系统协调小组，推动企业高管对信息系统的共识。这几件事做下来，效果非常不错。
回头看这段经历，我发现它跟今天企业上AI Agent面临的问题，结构一模一样。技术团队能把Agent搭起来、跑起来。但让Agent从"存在"变成"被真实使用"，这件事技术团队干不了，也不该他们干。工程师的逻辑是"系统上线=任务完成"，HR的逻辑是"系统上线=工作刚刚开始"。
这个分野，就是HR在AI时代的第一价值位。
具体怎么干？我试着梳理了一个五步框架：
第一步，战略澄清。 别急着选模型、搭Agent。先老老实实想清楚：企业要做什么？有什么能力和资源？当前最大的瓶颈是人不够用、流程太乱、还是决策太慢？不是看隔壁公司上了什么Agent你就跟着上——Agent不是军备竞赛，是岗位设置。你不需要设一个没活干的岗位。
第二步，岗位设计——把工作分成三类。 AI可以独立干的（数据录入、标准化报告），人机协作干的（简历筛选后HR终面、合同草拟后律师审核），必须人干的（战略决策、危机公关）。关键是"人机协作"这一类：谁先做？交接点在哪？Agent做到什么程度交给人？举个具体的例子：Agent筛完100份简历，给出10份推荐，HR看了之后可以推翻吗？可以——但需要记录推翻的原因。这个"记录原因"的动作，既让人能用起来（不信任时可以说不），又让Agent能越用越好（推翻的原因就是调提示词的素材）。
第三步，Agent岗匹配。 这跟招聘一个逻辑：人才画像→模型选型，岗位说明书→系统提示词，入职培训→知识库上传，试用期→"影子模式"。什么叫影子模式？Agent正常跑但不执行最终操作，让人看到它的决策，跟人的决策对比，逐步建立信任再放权。
第四步，动态评价——排查要按顺序来。 Agent做不好，别急着换模型，按这个顺序查：①提示词写清楚了吗？②工具描述准确吗、权限够吗？③知识库内容对吗、更新了吗？④上游给的数据质量行不行？⑤下游的人会正确使用Agent的产出吗？大部分问题根源在前四步，不在Agent本身。这就是企业系统工程的思维——绩效评价不能只看指标，要看整个链条。
第五步，持续改进。 Agent也需要"绩效管理"。该升级的升级，该调提示词的调提示词，该下线的下线。Agent的成本是可变成本——一个Agent设了不用、用不好、该升级没升级，跟养一个闲人没区别。
这个框架的核心思想就一句话：不是所有好的Agent岗位都要设。先搞清楚企业要做什么，把自己的能力和资源盘清楚，再决定要哪些Agent岗位。
五步总结一下：想清楚→分类→匹配→排查→改进。 每一步都不新鲜，每一步都是OD的老本行。
但有一件事跟管人不一样。你没法给Agent涨工资来激励它，你只能调它的工作指令、工具权限、考核标准。这是管Agent和管人的本质区别：
所以别怕试。Agent的试错成本极低，这是它最大的管理优势。大胆验证，不行就改。
Advisor视角：HR具体做什么？
说到底，企业老板和HR最关心的不是理论框架，是"我该干什么"。
三件事。
第一，做"岗位审计"。 识别企业里哪些工作任务适合交给Agent，哪些必须保留给人。不需要你会写代码——需要的是你对业务和人的理解。HR天天跟岗位打交道，这件事天然是你的。
第二，设计"协作流程"。 人跟Agent怎么配合？谁先做？交接点在哪？出了问题算谁的？Agent的建议，人可以推翻吗？画一张流程图，把人的角色和Agent的角色标清楚。协作流程没设计好，Agent能力再强也用不起来——就像我当年那家科研企业，系统建好了，跨部门协同没打通，一样用不起来。
第三，建立"Agent治理机制"。 定期review Agent的表现，校准AI评分器的偏差，决定Agent是"晋升"还是"淘汰"。这跟你主持人才盘点会的逻辑完全一样，只不过评价对象从人变成了Agent。
怎么判断协作效果好不好？看五个指标：任务完成速度有没有变快、决策质量有没有提升、AI采纳率有没有在涨、反馈有效率——员工提的改进建议有没有落实、错误修复速度——Agent出错后多久被发现和纠正。五个指标都不需要写代码，看的是"人机协同"的系统效能，不是Agent一个人的表现分数。
这三件事，都不需要你会写代码。但需要你完成三个转变：
认知上，从"管人"变成"管劳动力"——包括人和Agent。Agent是新型劳动力，HR不管，谁来管？
知识上，不需要变成技术专家，但得知道Agent能干什么、不能干什么、什么时候该用、什么时候不该用。
能力上，岗位审计、协作流程设计、Agent治理——这三样是HR在AI时代的核心新能力。好消息是，它们跟OD的基本功完全相通。
回头看我这几天的折腾——被一道题难住、翻了十几篇资料、拿两个Agent做了个实验——其实就搞明白了一件事：给Agent评绩效，本质上不是技术问题，是组织问题。
技术圈已经把评估框架搭好了——Task、Trial、Trajectory，够用了。但谁来用这个框架？谁来定义"什么叫好"？谁来保证Agent设了之后真的被用起来？谁来决定Agent该升级还是该淘汰？
这些事，HR做了几十年了。只不过以前管的是人，现在多了一种"员工"叫Agent。
HR不用慌。你手里那套OD方法论，换个对象一样好用。关键是敢不敢往前站一步——在技术团队搭Agent之前，就告诉他们：别急着搭，先想清楚这个"岗位"该不该设。
这篇东西，是我被一道题难住之后，翻了几天资料、拿两个Agent做了个实验、从三个视角梳理出来的一点思考。它一定不成熟。Agent绩效评价这个话题太新了，真正的实践者还少。但我越来越确信一件事：AI时代最大的障碍不是技术，是组织。系统建好了没人用，Agent部署了人不信——这个问题的解法，不在技术圈，在HR和OD的领地里。
或许你可以提出更好的问题。我们一起探索。
对了，不知道那位给我出题的IT圈朋友看到这里，会怎么想。这道题我抠了几天脑壳，折腾出来的答案未必对。但如果它能让更多做HR的人意识到——Agent的事，不是纯技术的事——那这道题就没白做。
孙大脑袋说AI · 第3篇
这个公众号记录我怎么用AI重新理解工作和生活——写文章、带娃、搭工具、踩坑，每一步都写下来。不是教学，是真实记录。
想看我搭的那些AI工具？ 扫码关注服务号「搞个锤子AI」，学业诊断、知识点百科、AI小工具都在那边。
想读后面的故事？ 关注「孙大脑袋说」，不保证周更，但保证每篇有料。
搞个锤子AI 品牌专栏 | 个人订阅号「孙大脑袋说」× 公司服务号「搞个锤子AI」
