错误的默认设置，为何企业 AI Agent 难以被采用

你是否看到了这些公司提供的 AI Agent 界面之间的相似之处？有聊天会话，有模型选择，有语气设置，然后是 MCP 连接、技能、记忆。它们正在确立所谓的“行业标准”，而如今，无论是谁要为自己或公司构建新的 AI Agent，都会遵循同一套标准。

而且，无论你是否意识到，这些标准都很糟糕。接下来我会告诉你原因。

你看，当工程师构建一个带有不同参数的 CLI，或是一个有不同设置的产品时，他们通常并不知道用户想要什么，于是便给用户一个选择、一个设置。如此一来，他们巧妙地将“决策者”的角色转移给了你。因此，每当你使用当前这种标准的 AI 聊天界面时，脑中都会浮现许多问题：

• 我在哪里讨论过 X？

• 现在上下文快满了，我应该压缩这段对话，还是新开一个对话？

• 我该换用哪个模型？

• 我应该连接哪些连接器？

而且，每一项都需要你自己做决定。这就是你在说工程师的语言。

iOS 相较于 Android 最令人印象深刻的第一印象之一，就是 iPhone 永远是开箱即用的。当然，你的选择有限，也被“锁定”在生态中；但事实上，对大多数用户来说，并不需要那么多定制才能让它正常工作。你只要拿起手机开始使用，它就能正常运作，还有什么比这更方便？

公平地说，两种方式之所以都存在，是因为有些人追求选择的自由，想要更多配置；正是这些人让如今的世界如此丰富美好。但是，如果你是一家希望让数百乃至数千名员工更好地采用 AI 的企业，你就必须构建 iPhone 版本。因为它显然是为大规模采用而优化的。你不该为了少数高级用户的奢侈需求，牺牲绝大多数用户。这正是我今天想讨论的：

你需要打破 错误的默认设置（The Wrong Defaults）。

我从小就被教导：如果你相信自己做的是对的事，即便所有人都说应该走另一条路，也要相信直觉并付诸行动。所以，以下是我的看法。

如果你看看当前的企业 AI 格局——顺便说一句，它几乎无处不在于新闻之中——就会发现，无论大小公司都急于推动 AI 采用，因为它们害怕落后。它们向 AI 公司购买许可证，接着又基于这些 AI 公司提供的 行业标准 构建自己的 AI Agent，并鼓励人们尝试这些新 AI 工具。这是一个无休止的循环。唯一的赢家是那些 AI 公司，而最终用户才是受苦的人。但如果你的公司要求你使用或构建这类工具，又有谁会在乎？我在乎。

就像你和朋友或同事聊天一样：你会为每个人保留一段长期聊天记录。你打开聊天窗口，然后开始输入。它本来就应该这样工作，本来就应该如此。不要被所谓标准洗脑，去构建一个多会话聊天界面。如果你是 AI Agent 构建者，却无法解决上下文预算或 AI 幻觉问题，那是你的问题。不要把这些问题转嫁给用户，还期待他们“采用”你的工具。

剧透一下，你可以通过观察人类记忆如何运作来做到这一点，因为我们的大脑也有类似的“上下文预算”，只是大得多。我们同样会遗忘。把这种判断应用到你的 AI 上，你会找到自己的解决方案。

无论你在工作中使用 Slack、Teams 还是其他应用，在 AI Agent 与这些聊天平台之间复制和粘贴聊天内容都非常荒谬。这是一种完全不合理的标准。

你的聊天平台本身已经承载了上下文——与同事的对话、群聊中作出的决定、分享过的文件、交换过的链接。为什么还要强迫用户离开这些上下文，打开另一个工具，把问题粘贴进去，获得回复后，再复制粘贴回来？

现在，想象一个世界：你的 AI Agent 就存在于同一个聊天空间中。你和它交流的方式，就像和同事交流一样。你的同事能看到 Agent 说了什么，Agent 也能看到同事说了什么。没有上下文丢失，没有复制粘贴，也不用切换标签页。没错，这听上去像科幻——但其实不是。

AI 行业希望你尽可能多地构建 AI Agent。这正是它们赚钱的方式。因此，它们（强烈建议你非常慢地读这一句）为你的公司构建平台，让你的公司为员工构建平台，再让员工构建各自专用的个人助理 AI Agent。而你正中其下怀。你消耗 token 来构建 Agent，又消耗 token 来使用 Agent。双重收费，真疼。如果你的公司同时付费给两家 AI 供应商？那就是四重收费，双倍疼痛。

问题是，你为什么要构建这么多 Agent？它们会说，专用 Agent 更聪明、幻觉更少、更可靠。但真的是这样吗？如果你只构建一个通用 Agent，并让它根据每位用户的个性和角色进行定制，会怎样？如果你构建一个空容器，让它根据用户提出的问题加载不同技能，会怎样？这难道不比逐个构建、逐个定制 Agent 更好吗？

这不仅能优化构建和运营 Agent 的成本，也让你更容易在 Agent 基础设施上实施治理和安全措施。而且，每位员工都能立刻拥有自己的个人助理。一石三鸟，甚至更多。

因此，你想让 Agent 更聪明，于是将它连接到更多 API 和系统。好，这很合理。听起来简单直接，事实也确实如此。但这里有一个微妙的问题。假设你通过 jira-cli 连接 Jira，通过 confluence-cli 连接 Confluence，通过 google-cli 连接 Google，等等。你到底要支持多少个 CLI？每增加一个新集成，都需要一名工程师介入。再说一次，甚至不要想向终端用户提及 CLI 配置——你说的是外星语言。

答案比你想象的简单得多。你觉得这些 CLI 是如何与 API 协作的？当然是通过 TCP/HTTP 调用。这些 CLI 的共同本质，是一种通过 HTTP 传输数据的通用工具。而 Linux 有一个非常强大的程序可以做到这一点：curl。借助 curl，你的 AI Agent 就能自然地访问每一个 API。Agent 只需要知道连接到哪里、如何认证，以及你希望它用该 API 做什么；这些内容都可以通过一条非常简单的文本指令描述。顺便说一句，LLM 模型对知名公开 API 文档（例如 Atlassian、MS Graph API 等）了解很多，所以你甚至不需要在技能指令中重复这类细节。

我知道，市面上所有 AI 代码助手编辑器都有 MCP 或 Connectors 配置，但它们是完全不同的产品，有完全不同的目标和受众。记住，你的目标是 AI 采用，因此少一次点击，就可能多出十位潜在用户。

从公司的角度看，让 LLM 模型掌握公司的知识是合理的。一项常见建议是构建知识库层，让 LLM 能够可靠地从中提取数据，并提供准确引用和原文引述。我想，唯一能让你亲自试验并感受到痛苦的方式，就是自己实现它并测试结果。你会体验到：构建和维护这个知识库并非易事。它是一个庞大且永无止境的组件，需要持续监控、数据摄取、无冲突处理、及时更新、最佳排序等工作。而且，检索方法也会因你拥有的数据而异。关于 RAG 的论文多到足以轻易让你不知所措。

相比之下，模型的自我推理能力正变得越来越强。因此，与其依赖那些复杂的 RAG 管道，不如把来自不同来源的杂乱数据交给模型，再提供清晰的指令，然后依靠它们的推理过程。我发现，大多数时候得到的回答都惊人地准确，而巨大的好处在于移除了一个庞大的工程组件。想想复杂性、优化与用户体验之间的权衡。只有你能平衡这一切。

将公司知识纳入 LLM 模型的另一种方式是微调。但持续学习很难。很难在持续向模型添加更多知识的同时，确保它们变得更好。出于某些原因，新加入的数据对核心记忆的影响，并没有我们预期的那么大。也别忘了，公司要花费巨资进行所有这些实验，然后祈祷它们能够奏效。

一种可能的方法是，在等待微调技术变得更好的同时，依赖通过技能、工具或任何可以接入 Agent 的连接器发起 API 调用所获取的实时数据。没错，两个用户提出相同的问题，会触发相同的 API 调用——这很浪费，也有重复。但准确优先于“优化过但错误”的结果。建立用户信任没有任何妥协余地。

行业从复杂性中获利，它们不会替你解决这些问题。因此，要么你亲自打破默认设置并充满信心地构建，要么随波逐流，期待人们觉得你的工具有用并继续使用它。选择权在你。

Do you see the similarities across AI agent interfaces that these companies give you? There are chat sessions, there are model selections, there are tone settings, then there are MCP connections, there are skills, there are memories. They are setting up the “industry standards” and now whoever is building a new AI agent for themselves or for their companies, they follow the same standard.

And whether you realize it or not, these standards suck, and I’m gonna tell you why.

You see, when engineers build a CLI with different flags or a product with different settings, they usually don’t know what the user wants, so they give them a choice, a setting. And with that, they nicely shift the “decision maker” role to you. So every time using the current standard AI chat interfaces, many questions raise inside your head:

• Where did I discuss X?

• Should I compact this conversation now since the context is almost full, or open a new conversation?

• What other model should I use?

• What connectors should I connect to?

And you have to make decision for each of them. This is you speaking engineering language.

One of the best first impressions with iOS (comparing with vs Android) is that iPhones are always ready-to-use. Sure, you have limited choices, you’re “locked in”, but the truth is for the majority of users, you don’t need that much customization for it to work. You just pick up the phone and use it, it just works, what could be more convenient?

Now, to be fair, both exist because there are people who want the freedom of choices, they want more configurations, making the world as beautiful as it is now. But, if you’re an enterprise trying to get hundreds or thousands of employees to adopt AI better, you must build the iPhone version. Because obviously it’s optimized for mass adoption. You don’t want to sacrifice the majority of users for the luxury of a few power users. And that is what I want to talk about today:

You need to break The Wrong Defaults.

I have been taught since I was little: if you believe you’re doing the right thing, even though everyone else says the other way, then trust your gut and do it. So here is my take.

If you look at the enterprise AI landscape right now – it’s all over the news by the way – you can tell that companies large and small are desperate for AI adoption as they’re afraid of being left behind. They buy licenses from the AI companies, then they build their own AI agents using the industry standards , also from those AI companies. They’re encouraging people to try the new AI tools. It’s a never-ending cycle. The only winners are those AI companies. And the end-users are the ones who suffer. But who cares if your company asks you to use or build such tools? I do.

The same way that you talk with your friends or your coworker: you have one long chat for each of them. You open the chat, and you start typing. That’s how it should work. That’s how it should be. Don’t be brainwashed by the standard and build a multi-session chat interface. If you are an AI agent builder and you cannot solve the context budget, or AI hallucination problem, that’s on you. Don’t put that on the users and expect them to “adopt” your tool.

Spoiler alert, you can do that by simply observing how human memory work, because our brain has a similar “context budget”, just much larger. We’re forgetting things too. Apply that judgement to your AI, you’ll find your own solutions.

Whether you’re using Slack or Teams or any other application at work, copying and pasting chats between the AI agents and those chat platforms is ridiculous. It’s an absolutely absurd standard.

Your chat platform already holds context - conversations with coworkers, decisions made in group chats, files shared, links exchanged. Why would you force the user to leave that context, open another tool, paste their question there, get a response, then copy/paste it back?

Now just imagine a world where your AI agent lives right there in the same chat. You talk to it the same way you talk to your coworker. Your coworker can see what the agent said. The agent can see what your coworker said. No context lost. No copy-paste. No switching tabs. Yeah, it’s sci-fi stuff - except it’s not.

The AI industry wants you to build as many AI agents as possible. That’s how they make money. So they (highly recommend you read this very slowly) build platforms for your company to build platforms for its employees to build their specialized, personal assistant AI agents. And you play right into their hands. You burn tokens to build agents, then burn tokens to use agents. Double charge, ouch. And if your company pays for two AI vendors? Quadruple charge, double ouch.

The question is, why do you want to build so many agents? They say specialized agents are smarter, less hallucination, more reliable. But is it? What if you build only one general-purpose agent that could be customized for every single user, depending on their personalities and their roles? What if you build an empty vessel, that can load different skills depending on what is asked? Isn’t that better than individually built, customized agents?

It not only optimizes the cost of building and operating the agent. It is also so much easier to apply governance and security to the agent’s infrastructure. And each employee has their own personal assistant instantly. One stone, three+ birds.

So you want your agents to be smarter, so you hook it up to additional APIs and systems. OK, that’s fair. It sounds simple and straightforward, and it is. But here is a subtle fact. If you, say, connect to Jira via jira-cli, connect to Confluence via confluence-cli, connect to Google via google-cli, the list goes on. How many CLIs are you going to support? Every new integration would require an engineer to get involved. Again, don’t even think about mentioning CLI setup to the end-user - you’re speaking alien language.

The answer is much simpler than you thought. How do you think those CLIs work with the APIs? By TCP/HTTP calls, of course. The common theme of all of those CLIs is a generic tool to transfer data via HTTP. And Linux has a very powerful program for that: curl. With curl, your AI agent can naturally reach every API. All the agent needs to know is where to connect, how to authenticate, and what you want to do with it, which you can describe in a very simple text instruction. By the way, LLM models know a lot about public well-known API documents (like Atlassian, MS Graph API, etc), so you don’t even need to repeat such details in the skill instruction.

I know all AI code assistant editors out there have the MCP or Connectors configurations, but they are completely different products with completely different goals and audiences. Remember, your goal is AI adoption, so one less click is ten more potential users.

From a company’s perspective, it makes sense for the LLM models to have the company’s knowledge. One common recommendation is building a knowledge-base layer that the LLM can reliably pull data from with exact citations and quotes. I suppose the only way you can experiment and feel the pain is to implement this yourself and test the results. What you will experience is that building and maintaining this KB is non-trivial. It’s a huge never-ending component that requires constant monitoring, data ingestion, conflict-free, up-to-date, best ranking, etc. And the retrieval methods vary depending on the data you have as well. There are many papers about RAG that will easily overwhelm you.

In contrast, models are getting better and better at self-reasoning. So instead of relying on those complicated RAG pipelines, you can give the models messy data from different sources, a clear instruction, then you can count on their reasoning process. I found the responses are surprisingly accurate most of the time, with the huge upside of removing a massive engineering component. Think about the trade-off between complexity, optimization, and user experience. Only you can balance all of those.

Another way of incorporating a company’s knowledge into LLM models is fine-tuning. But continuous learning is hard. It’s hard to keep adding more knowledge into the models while making sure they get better. For some reason, the newly added data doesn’t have as much impact on the core memory as we expected. And don’t forget it costs companies a fortune to do all of this experimentation and cross their fingers for it to work.

One possible approach, while we’re waiting for fine-tuning to get better, is to rely on live data from API calls via skills or tools or any connectors you could plug into your agents. Yes, the same question from two users would trigger the same API calls - wasteful and repeated. But accuracy beats optimized and wrong. Building users’ trust is non-negotiable.

The industry profits from the complexity. They won’t fix this for you. So either you break the defaults yourself and build with confidence , or follow the crowd and hope people find your tool useful and stick with it. Your choice.