关于 Agent，最常见的误区其实不复杂，但反复出现。
第一个误区，是把 Agent 做成 prompt。
也就是把所有业务规则、状态逻辑、风险边界、工具说明全都塞进 prompt 里。 这种系统一开始看起来很快，但后面几乎一定会失控。
第二个误区，是把 Agent 做成玩具。
它能演示，但不能真实推进任务。 往往看起来很聪明，实际上没有可验证的完成条件。
第三个误区，是把 Agent 做成黑箱。
但如果只把这些误区理解成“做得不够成熟”，还是太客气了。
第 39 章真正要强调的是：这些误区并不是偶然失误，而是会系统性地把项目带向错误方向的设计偏差。它们之所以危险，不是因为不好看，而是因为它们会让团队在错误目标上越投入越深。
先看“把 Agent 做成 prompt”。
这类系统的共同特征，是把业务规则、状态逻辑、风险边界、工具说明、例外处理和输出格式全部塞进一大段提示词里。短期看，这样推进很快；长期看，它几乎一定会失控。因为一旦系统增长，prompt 会开始承担本不属于它的职责：对象建模、流程控制、权限表达、状态治理、错误恢复。结果就是所有东西都混在一个文本里，能跑，但不可维护、不可测试、不可验证。
因此，第一个误区真正的问题不是“写 prompt 太长”，而是：
它把本该属于系统结构的责任，错误地压给了模型上下文。再看“把 Agent 做成玩具”。
这种系统通常 demo 很漂亮：会说话，会调用几个工具，会多轮交互，看起来很有灵性。但它们往往没有清晰任务对象、没有外部成功验证、没有稳定终态、没有恢复策略，也没有真正的审批与审计。换句话说，它们更像是交互表演，而不是任务系统。
玩具化最大的问题，不是“没有商业价值”这么简单，而是它会制造一种危险错觉：团队误以为自己已经离生产很近，实际上只是把语言表现包装得很好。真正一进入真实环境，状态、权限、验证、成本和治理问题会同时爆出来。
第三个误区，是把 Agent 做成黑箱。
也就是系统能运行，但你说不清它为什么这样做、哪一步出了错、为什么这次成功下次失败、权限何时被放大、状态何时被污染、审批何时被绕过。这样的系统短期也许能跑，但长期几乎无法维护。因为一旦缺少 trace、eval、state visibility 和 failure attribution，任何改动都像在碰运气。
所以，黑箱并不只是“可解释性不够”，而是“系统失去了被工程化管理的可能”。
第四个常见误区，是把 Agent 做成能力崇拜项目。
这类团队总在追问：要不要换更大模型、要不要更多 Agent、要不要更长上下文、要不要更复杂 planning。它们默认更强能力一定会自然转化成更强系统。但实际上，很多项目的问题根本不在能力上，而在对象不清、动作未分层、状态无治理、验证不外部化、治理缺失。能力升级只会把一个结构模糊的系统放大成一个成本更高、风险更大的系统。
第五个误区，是把 Agent 做成无主自动化。
也就是系统能执行很多动作，但没有清晰的授权链、审批链、审计链和责任链。谁批准了它，谁拥有最终中止权，谁对高风险动作负责，出了问题谁来解释，这些问题如果没有在设计里被显式写清楚，组织最终一定会拒绝真正把事情交给它做。
因此，第 39 章第一条结论应该是：
Agent 项目最危险的误区，不是“不够智能”，而是“把本该由系统承担的职责，错误地推给了模型、demo 或运气”。这五种误区看起来不同，但底层其实都指向同一个问题：边界没有被显式建出来。
把 Agent 做成 prompt，是对象边界和流程边界没建出来。 把 Agent 做成玩具，是任务边界和验证边界没建出来。 把 Agent 做成黑箱，是观测边界和归因边界没建出来。 把 Agent 做成能力崇拜项目，是设计边界被模型能力吞掉了。 把 Agent 做成无主自动化，是治理边界和责任边界没建出来。
所以，本章第二条结论应该是：
几乎所有常见误区，最终都可以被归结为一句话：系统边界没有被对象化、程序化和治理化。一旦这样理解，你就会发现避免误区的办法其实并不神秘。不是“更懂 prompt”，也不是“更会调模型”，而是回到更基础的工程动作：把对象写清楚，把动作分层，把状态建出来，把验证外部化，把审批和追踪做进去，把失败路径和止损路径先想明白。
所以，本章最后要留下的判断是：
Agent 真正的成熟，不是它看起来更像智能体，而是它越来越不像魔法，越来越像一个边界清楚、行为可见、失败可控的系统。