3/50。这是我在一次AI岗位技术测试中的得分，换算成百分制只有6分。
但讽刺的是，我拿到了这份工作。
当时我对完全自主的智能体架构几乎一无所知。虽然做过大语言模型流水线和一些小工具，但"让AI自己决定下一步做什么"这种设计模式，对我来说是全新的领域。这次失败反而让我学到了关键一课——不是关于智能体本身，而是关于如何面对陌生的工程问题。
面试时，我展示了测试结果。现在的CTO注意到我一直在用便宜的迷你模型做 endless testing，账单已经相当可观。他顺手用我的智能体跑了一遍当时最强的Opus模型。结果更尴尬：得分从3分掉到了2分。
问题根本不在模型。
我的代码结构其实很干净：基于插件的工具系统、一致的接口设计、半自主流水线，还加了结构约束。我的策略是"先限制再扩展"——给智能体特定工具解决一部分问题，再围绕这些抽象慢慢扩充能力，直到覆盖全部场景。
纸面上，这套架构无懈可击。实战中，它解不了题。
CTO告诉我，如果当初我只做一个最简单的循环：大模型+while循环+Python沙盒，让智能体执行代码（当然不是完全无限制的），基准测试能拿到80%的分数。不需要提示工程，不需要特殊工具，不需要高级抽象。
这不是说生产环境就该放任AI随便跑代码。核心教训是：我在"知道"之前就"建造"了。我假设自己懂该用什么抽象、该造什么工具、该怎么约束智能体。实际上我完全不懂，甚至对测试题目的领域毫无概念。
回头看，正确的做法是从简单开始。
先搭一个能跑通的基线：循环结构+安全的Python执行环境。有了这个底子，工具、约束、抽象这些附加层才有意义——它们只服务于三个目标：可靠性、成本、延迟。
更重要的是，这次经历让我真正理解了"智能体"是什么。传统软件里，要解决多种问题就得把复杂度显式编码进系统。智能体把这个逻辑颠倒了：复杂度藏在模型内部。
我总结了两点收获。
第一，实践层面。行业趋势是给智能体更多自主权，但讽刺的是，编程类智能体似乎还没跟上。Claude这类工具反而倾向于让我做更少自主、更"流水线化"的设计。如果给智能体安全的Python执行能力，Python本身就是一件灵活强大的工具。而随着Pydantic Monty这类框架出现，这件事正变得越来越简单。
第二，工程思维。从简单开始。在理解问题之前，别预设自己知道答案。
热门跟贴