使用智能体，保持自主权

来源：https://devindickerson.dev/posts/using-agents-keeping-agency/

使用智能体，保持自主权。我一直在思考：如今有多少决策不是我独立做出的？排在播放列表顶部的推荐剧集，列表最上方的品牌，聊天机器人自信满满地给出的答案。大多数都无伤大雅，而且几乎都能纠正：退掉订单、跳过剧集、重新搜索。

问题出在，当推荐固化为你难以轻易逆转的东西时。而在这方面，没有什么比编程智能体来得更快、更悄无声息。

启动一个新项目，数数头二十分钟里飞过的技术决策：语言、框架、数据库、认证提供商、托管目标、测试。在编程智能体出现之前，每个决策都是有意为之的，会权衡利弊、成本和可维护性，即使最终判断可能是错的。

我们现在还在那样权衡吗？我与开发者和产品负责人的交流，加上我自己的项目经验，得出的结论是“有时如此”。我记得自己早期的某个智能体项目，当时智能体选择了一个流行的BaaS（后端即服务），我就通过了。但后来发现，该领域的数据是文档型的，而且极其多态——这种数据很难被强行塞进关系型表里变成JSON blob。但那时，“以后再换”已经悄然变成了“重建认证、生成的API和存储”，因为那个便利的默认选项不仅仅是一个数据库。而现在，我正在为一个没有经过深思熟虑的决策付出代价。

在业余项目上，这不过是耸耸肩的事。但当我把这个轶事讲给数百位企业级和大型科技公司的工程师听时，它依然能引起共鸣，因为即使在那些环境中，他们也觉得感同身受。在需要证明AI能让我们更快的压力下，我们确实更快了。但是，通过跳过决策而获得的速度，是真正的速度，还是一笔贷款？

互联网的默认设置

那么，如果智能体在做出技术栈决策，这些建议从何而来？智能体对架构的“直觉”是其训练数据的统计回声。这并非凭空猜测；研究人员已经测量过。一项2025年对八个LLM的研究（https://arxiv.org/abs/2503.17181?ref=devindickerson.dev）发现，即使任务并不需要，它们也会过度使用主流库：在高达48%的案例中不必要地使用NumPy，在58%的高性能场景中默认使用Python，而Python在此处并非合适工具。而更适合其中多项任务的Rust，则出现了零次。作者对代价直言不讳：那些“优先考虑熟悉度和流行度而非适用性”的模型会引入安全漏洞和技术债务。

其机制是一个飞轮。普遍性意味着更多的代码、更多的文档、更多的论坛帖子，这些又成为更多的训练数据，从而在下一个模型更新中强化这种偏好。需要后端？给你一个最常用的，不管你的用例是什么。

而且这个循环已经不再是自然形成的。如今已经有一个生成式引擎优化行业，其全部产品就是让AI推荐你的东西；消费者版本，例如公司自己的“最佳平台”榜单被ChatGPT直接引用，已有文献记载（https://www.theatlantic.com/technology/2026/06/google-search-ai-optimization/687495/?ref=devindickerson.dev）。开发者工具版本则更为低调，但玩法相同：供应商发布 llms.txt 文件，让智能体优先阅读它们的文档，Mintlify（https://www.mintlify.com/docs/ai/llmstxt?ref=devindickerson.dev）可以零配置自动生成这些文件，Fern（https://buildwithfern.com/post/best-llms-txt-implementation-platforms-ai-discoverable-apis?ref=devindickerson.dev）则将其视为 robots.txt。这些都不是什么恶意行为；这是智能体时代理性的营销手段。但你聊天窗口中的推荐并非对你选项的中立调查。它是一场历史上最复杂的流行度竞赛的胜出者。

双向门与单向门

并非每个决策都同等重要。那些可以纠正的和那些不能纠正的决策之间的区别，有一个名字。贝索斯称之为双向门和单向门：那些可以低成本撤销的决策，以及那些你必须忍受的决策。你的样式库是双向门。你的数据模型、认证提供商、租户边界、合规姿态则是单向门。

但这些门并非固定不变。随着代码堆积，双向门会固化，而智能体最喜欢的手段就是将多个单向门打包在一个便利的选择后面。我之前通过的后端并非一个可逆的调用。它是一个数据模型和一个认证提供商，作为聊天中的一行代码出现，被归为双向门，因为它呈现出来的就是那个样子。

对于双向门，我的建议是让智能体放手去做。这正是流行技术栈赢得声誉的地方：它们经过实战检验、文档齐全、示例丰富。周六搭建一个待办事项应用？默认选项就行，和它争论只会浪费你的周六。

问题始于“对大多数项目都够用”的方案，在你项目中遇到了单向门。默认方案不知道你的合规制度、你的数据模型、你的增长曲线，也不知道你的团队已经在生产环境中运行了什么。而这些变量才是决定胜败的关键。它们存在于你的世界里，而不是训练数据中。即使你把它们粘贴到提示中，智能体也只是抓住了你问题的形状，而不了解你的问题本身。这个差距，在全新项目的第一天，和在别人十年前搭建的系统中进行下一次迁移时，同样真实存在。

更深层次的问题不在于默认选项总是错的，因为有时它是对的。而在于，在单向门上，实际上没有人真正做出决定：一个影响未来多年的选择，是在智能体已知信息与它需要知道的信息之间的缝隙中做出的，没有任何权衡被呈现出来。而这正是被博弈过的默认选项造成损害的地方：今天的智能体搜索引擎优化，而不是你的约束条件，正在决定你发布什么。

决策层

标准的反驳是操作员自律：要求智能体提供三个选项及其权衡。这有点用，前提是你记得住这么干。但提示是一种习惯，而习惯无法在团队中或周五下午被有效推广。每个聊天窗口都有它自己的裂缝，就像我在《裂缝之中》（https://devindickerson.dev/posts/in-the-seams/）一文中写到的：每次会话都要重新协商上下文，昨天的自律随着上下文窗口一同消失。真正的问题是层面问题。智能体的速度使得将架构决策压缩进实现细节并继续前进变得轻而易举，而这正是单向门在无人决策的情况下被通过的方式。这些调用应该属于会话之上，是有意为之且有人负责的，而不是在周末前的4:55临时发挥。

会话之上只解决了一半问题；决策还必须存放在智能体不会错过的地方。在项目持久、可共享的上下文中记录选择、被否决的替代方案以及做出决定时依据的约束条件：架构决策记录、智能体技能，以及平台在会话间携带的智能体记忆。这个上下文并非一劳永逸。它需要维护、保持更新，偶尔还要推倒重建，否则就会腐烂成智能体学会忽略的噪音。Cloudflare的工程师在使用智能体重构Next.js（https://blog.cloudflare.com/vinext/?ref=devindickerson.dev）时遇到了这一点。在基于Next.js自身测试套件进行构建时，智能体不仅重现了其功能，也重现了其过去的CVE漏洞。它们吸收了熟悉的模式，包括有漏洞的模式，而通过的测试并未将其暴露出来。Cloudflare自身的经验教训是缺少的一环：一个指向正确语料库的持久指令，“审查所有过去的CVE，确保我们没有漏洞”。

记录永无止境，因为项目会反驳回来。智能体开发能快速暴露错误的最初假设：你猜错的增长曲线、经不起实际考验的租户模型、让你陷入困境的认证选择。值得捕捉的决策，是那些值得重新审视的。而持久的上下文正是这些修订落定的地方，这样下一次会话就能从你学到的东西开始，而不是从你最初的假设开始。

而这种有观点倾向的部分并非总是项目特有的。约束条件、权衡方法论、你的组织已经定下的“为工作负载选择合适技术”的调用，都是组织层面的，它们不应只存在于IDE中。将它们融入位于实现之上、可在团队间共享的上下文架构中：即插即用的智能体技能、参考模式、一个暴露上下文数据库的MCP服务器，供所有团队的智能体读取。

你拥有结果，所以不要委托“为什么”

智能体时代将继续偏向默认选项。训练循环奖励流行度，而证明AI生产力的压力也不会消失。所以，请确定你的单向门在哪里，有意地做出这些选择，并将决策写下来，让你明天的智能体能读到。你可以在其他所有方面在速度和严谨性之间做出合理的权衡。

你可以纠正大多数默认选项，但单向门是个例外：你在那里接受的默认选项不会被退回，而是会被导入、被依赖、被发布。在这里，速度和便利并非免费。你的自主权是你仍然能控制的一个变量。智能体应该扩大你的选项空间，而不是悄悄缩小它。如果你委托了“怎么做”，请确保你仍然拥有“为什么”。

订阅

将新文章发送到您的邮箱。