8.0
热点
AI SCORE
编程提效2026-09-28 11:33
生产环境常青的开源 LLM：没人谈但一直出现
dev.to · AI#LLM#AI Agent#工程实践
Editor brief · 编辑速览
文章揭示生产堆栈中被忽视但实际广泛使用的 LLM，指出 Agent 定义模糊导致工程错误，区分了「聊天界面」和真正「Agent」的本质差异。
我在 AI 领域花了大量时间——读论文、写代码、和正在交付项目的工程师交流。关于演示展示的东西和实际生产系统的样子之间存在一条鸿沟，而没有人愿意完全诚实地说清楚。
所以这是我关于当前真实状况的坦诚看法。
现在所有人都在把一切叫做"Agent"。一个调用了工具的函数？Agent。有记忆的聊天机器人？Agent。一个带循环的脚本？Agent。
这种语义稀释不只是文字问题，它正在导致真实的工程失误。
当你对自己要构建的东西没有精确定义时，你会在简单的 pipeline 上过度工程，也会对真正复杂的系统工程不足。我见过团队花几周时间为本来一个结构良好的 prompt 就能搞定的工作流添加"Agent 化"编排。
我反复回归的这个定义是：Agent 是一个有目标（而不仅仅是指令）的系统。它决定下一步做什么。它处理失败。它知道何时完成。
其他一切都只是一个花哨的函数调用。
🟢 如果你的系统需要人告诉它每一步，那它不是 Agent，只是一个聊天界面。
🔵 如果你的系统能从失败的工具调用中恢复并尝试不同方案，你正在接近真正的 Agent。
✅ 如果你的系统能将目标分解为子任务并委派它们，那就是真正的 Agent。
从我关注和交流的团队那里看到的真实图景：
大多数真实的 Agent 部署都是窄场景的。它们把一件事做好。客服分流、文档提取、对特定代码库的代码审查。它们不是通用推理引擎，而是带有决策层智能的目的构建 pipeline。
取得好结果的团队不是在追逐最新的模型发布，而是在以下方面精益求精：
☑️ 工具设计——Agent 实际能调用什么，接口有多干净
☑️ 失败处理——当工具返回无用结果时会发生什么
☑️ 可观测性——你能否追溯到 Agent 做出某个决策的完整原因
得到糟糕结果的团队是那些把 GPT-4 换成最新前沿模型、期望不同行为却什么都不改的团队。
最近我反复看到的一件事：Anthropic 的 CEO 即将与特朗普总统共进晚餐（TechCrunch AI）。这将是 Dario Amodei 和 Donald Trump 之的首次一对一会议...
值得一读：https://techcrunch.com/2026/09/27/anthropics-ceo-is-about-to-have-dinner-with-president-trump/
最近我反复看到的另一件事：Muse 能克服 Meta 的信任问题吗？（TechCrunch AI）。在 Equity 节目中，我们讨论了 Meta 的 AI 发布如何成功抢走了 OpenAI 和 Anthropic 的风头...
值得一读：https://techcrunch.com/2026/09/27/can-muse-overcome-metas-trust-issues/
最近我反复看到的还有：Anthropic 的 Dario Amodei 登上了 SNL（TechCrunch AI）。"AI 是恶魔，而我它的制造者。"...
值得一读：https://techcrunch.com/2026/09/27/anthropics-dario-amodei-gets-the-snl-treatment/
LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel。每个月都有新框架出现，总有人在写文章说旧的已经死了。
我真正认为的是：框架没有模式重要。
无论你使用哪个框架，真正持续有效的模式是：
✔️ 先计划再执行。有一个推理步骤生成计划，然后有独立的执行步骤来遵循它。不要混在一起。
✔️ 分离检索和推理。获取上下文和使用上下文是不同的任务。混为一谈的系统会困惑。
✔️ 明确的交接。当一个 Agent 把工作移交给另一个时，交接应该是结构化的并被记录的。不是通过 prompt 传递一个字符串。
我用三个不同的框架重建了相同的架构，每次结果都相似。框架是脚手架，架构才是建筑本身。
RAG 现在是标配。几乎每个接触专有数据的生产 AI 系统都在用某种形式的 RAG。但有一个教程没有好好覆盖的问题。
分块边界是错的。
当你把文档拆分成块并嵌入时，你正在对什么上下文应该在一起做出假设。这些假设往往是错的。一段文字只有结合前一段才能理解，却被单独检索出来，模型对缺失的上下文产生幻觉。
🟢 更好的分块策略有帮助。重叠窗口、语义分块、父文档检索。
🔵 但真正的修复是重新思考你在存储什么。有时候正确的存储对象不是原始文本而是信息的结构化表示。
✅ 如果你的 RAG pipeline 返回的是技术正确但上下文无用的结果，问题几乎肯定在分块或元数据，而不是嵌入模型。
模型会继续变得更好。上下文窗口会继续扩展。每个 token 的成本会继续下降。
这些都不会改变基本的工程挑战：构建在你不在盯着的时候也能正确运行的可信系统。
这才是值得解决的问题。治理、可观测性和可靠的工具使用。而不是追逐基准测试。
在未来两年真正重要的工程师，是那些能构建出其他工程师可以维护和信任的 AI 系统的工程师。这是一套不同于微调或 prompt 工程的技能。
它更接近系统设计，而不是模型研究。
如果这些与你正在构建的东西产生共鸣，或者你有完全不同的看法，我想听听。在评论区分享你的经历。这个领域真正有趣的对话不在主题演讲里——而是在那些人们真正坦诚什么有效的帖子线程里。