昨天跟一个 HR 聊了挺久。他们团队想请我去讲一门课，主题是"怎么搭 Agent"。
背景是这样：他们整个 HR 团队都在推 AI 提效，内部分成了单点提效、流程提效、组织提效三个层级。团队里已经有人在用 AI Coding 工具、低代码平台拉内部数据做小网页，也有人用 Co-Work 之类的协作工具。不算完全不会用，但碰到了瓶颈。
他们最困惑的一个点是：做出来的小网页，第一眼看挺好，数据能展示，页面也漂亮。但是然后呢？如果只是看数据，直接把 MCP 挂上去问就行了，何必做成网页？如果要给别人看，又涉及部署、维护、权限，普通业务同学根本兜不住。所以他们想知道，"你平常是怎么搭 Agent 的"。
聊完之后我一直在想这件事。不是想怎么回答他们的问题，而是觉得这个问题本身就藏着好几个误区。记录一下。
误区一：把 AI 提效等同于"做 Agent"
这是我听到的最普遍的混淆。大家一说 AI 提效，脑子里的画面就是搭一个 Agent。好像不做 Agent，就不算在认真搞 AI。
但你仔细想想，AI 提效的工具形态其实很多。有些场景你只需要一个查询接口，让 AI 能帮你问数据，那做个 MCP 就够了。有些场景你需要几个人协作看一个东西，或者收集一些信息，那做个网页没问题。有些场景是固定流程跑得快一点，那是 Workflow 的事。只有当一个任务路径不确定、需要多轮推进、中间可能失败需要恢复、需要动态选择工具的时候，才值得上 Agent。
所以第一个判断应该是：这个场景需要什么形态来承载？而不是"我要不要做一个 Agent"。
拿 HR 的场景举例。员工问政策、查福利、看流程，这些是查询类的，挂个 MCP 让 AI 直接回答最自然。内部搞个活动要收报名信息、展示数据看板，这是展示和操作类的，做个网页就行。入职手续一步步审批走完，这是固定流程，Workflow 足够。只有像"帮我从 50 份简历里筛出最合适的 3 个人，还要交叉验证背景、评估文化匹配"这种开放式任务，才真正需要 Agent 的能力。
形态选错了，做出来的东西要么过度复杂（为了一个查询场景搭了整套 Agent），要么能力不足（用一个静态网页试图做动态决策）。先判断场景，再选工具。这个顺序不能反。
误区二：以为"我能用"就等于"别人能用"
这是第二个巨大的误解。一个人用 AI Coding 做出一个小工具，自己用得挺开心，就觉得可以推给团队用了。但单人自用和多人共享之间，隔着一条看不见的线。这条线叫工程稳定。
个人工具可以靠作者的记忆运转：坏了自己修，数据错了自己知道怎么补，权限粗糙点也只影响自己。但一旦给别人用，每一个"自己知道"的东西都会变成一个坑。别人不知道它为什么突然不能用了，不知道数据口径变没变，不知道出了问题找谁。
这时候你需要的不是更好的 AI Coding 能力，而是工程基础设施：部署、监控、日志、权限管理、回滚机制、事故响应流程。这些东西不是一个两小时的 AI 培训能覆盖的，也不是 AI 本身能替你解决的。AI 可以帮你写代码，但它不会替组织承担运维责任。
所以我的判断是：单点提效确实可以靠个人学习解决，但流程提效和组织提效，本质上是组织能力建设的问题，不是工具培训的问题。指望通过一两次培训让业务同学从"给自己用"跨越到"给团队用"，不太现实。更现实的路是：业务同学负责原型和验证，平台团队负责生产化和稳定运行，中间有明确的交接标准。
误区三：觉得 Agent 难在"模型+工具+知识库"
即便真的需要做 Agent，很多人对 Agent 的理解也停留在表面：找个模型，挂几个工具，接个知识库，就是 Agent 了。这个组合能做 Demo，但离真正稳定跑起来差太远了。
Agent 真正难的地方是中间的 Harness 过程。所谓 Harness，就是让 Agent 稳定运行的那一整套机制：状态怎么保存，工具权限怎么控制，哪些操作需要人来审批，出错了怎么恢复，每次运行的轨迹怎么记录，怎么评估它比上周跑得好还是差。这些问题一个比一个不性感，但每一个都决定着这个 Agent 能不能从 Demo 变成真正可用的东西。
所以对普通同学来说，从零搭一个成熟 Agent 不是正确的路。更好的方式是：把你的业务想法包装在已有的成熟 Agent 能力上面。比如前端提供用户的输入口，核心的智能处理部分调用后端成熟的 AI 产品（不管是 Claude Code 的 SDK、某个 CLI 的远程调用、还是企业内部的 Agent 平台），处理完之后对输出做一些规范，再接回到你的业务流程里。你负责定义"要做什么"和"做得对不对"，平台负责"怎么稳定地做"。
这个分工才是当前阶段大多数非技术人员用 Agent 能力的正确姿势。不是降低要求，是找对边界。
误区四：写了 Plan 就以为方向是对的
最后一个感触来自我自己最近的经历。我在做一个 App 的时候，功能做出来了，但怎么调都不太对。反复改了几版之后我忽然想起来，我这个东西和一个开源项目的功能很相似。于是让 AI 去调研那个项目的架构，结果发现我之前的设计从根上就有很多不对的地方。
这件事给我的提醒很直接：写 Plan 不等于方向对。
我以前每次让 AI 干活之前都会先让它写 Plan。Plan 的好处是让 AI 在长时间工作的时候不至于游离目标，干着干着忘了自己在干嘛。这一点没问题。但 Plan 还有另一层价值，就是方向本身是否正确。如果你在一个自己不熟悉的领域里，你写出来的 Plan（或者让 AI 写出来的 Plan）很可能方向就是错的。这时候 Plan 越详细，AI 执行得越认真，结果可能越歪。
所以我现在的做法是：如果涉及到我不确定"什么是好的"的领域，我会先让 AI 去外面找最佳实践。看看同类的开源项目怎么做的，看看官方文档推荐什么架构，看看别人踩过什么坑。基于这些外部输入，再来写 Plan。这样 Plan 指向的方向至少是经过验证的，而不是 AI 在真空里编出来的。
先去找什么是好的，再来规划怎么做。这个顺序，比"帮我搭一个 Agent"重要得多。
回到那门课
如果最后真要给他们讲，我不会把题目定成"如何搭建 Agent"。这个题目本身就把问题带偏了。
我更想讲的是四件事：第一，怎么判断一个场景该做成什么形态。第二，从"自己用"到"别人用"中间差的是什么。第三，如果确实需要 Agent 能力，怎么借力而不是从零开始。第四，在不熟悉的领域里，怎么确保你的方向不是在跑偏。
这四件事比具体的工具操作重要得多。工具会迭代，但判断力的框架不会过时。
真正的组织提效，不是让每个人都造车。是让每个人知道什么时候该骑车、什么时候该坐车、什么时候该修路。