#大模型 · AI 短帖与讨论

2026年的Agentic Engineering（智能体工程）不在于追逐最新模型。🤖 而在于围绕那些真正能通过生产环境考验的模型构建系统。 优秀的prompt能帮你做出演示Demo。 优秀的architecture才能帮你打造产品。 以下是每位工程师都应了解的Agentic AI（智能体AI）技术栈 👇 🧠 LLMs + Reasoning Models（推理模型） Understand what the model can reason through on its own before adding more agents, tools or complexity. 🧩 Context Engineering（上下文工程） Prompt engineering（提示词工程）只是其中一部分。 真正的技术难点在于设计模型所见的一切：指令、数据、工具、记忆与状态。 💾 记忆架构 会话记忆、语义检索与情景记忆解决的是完全不同的问题。 🤝 智能体工作流 复杂系统越来越需要专业化智能体、交接、状态管理与故障恢复。 🔌 MCP + 工具连接 代理在与真实系统、API 和企业数据交互时才会变得强大。 🚦 Model Routing（模型路由）+ AI Gateways（AI 网关） 并非所有任务都需要你最强大的模型。 按能力、延迟、成本和风险进行路由。 🛡️ Guardrails（护栏）+ Security（安全） 你赋予代理的自主权越高，权限、验证和人工干预就越重要。 🔍 Observability（可观测性）+ Evaluation（评估） 你需要对以下内容具备可见性： → agent 看到了什么 → 它决定了什么 → 它使用了哪个工具 → 工作流在何处断裂 最大的转变？ Agentic Engineering（智能体工程）正变得越来越不侧重于"使用 LLM"…… ……而更多地转向围绕智能的分布式系统工程。 最优秀的 Agentic AI 工程师将不仅仅是了解模型。 他们将懂得如何让模型在现实世界中变得可靠、可观测、安全、成本高效且实用。 真正的工程从这里开始。🚀 #AgenticAI #AI #ArtificialIntelligence #AIEngineering #LLM #GenerativeAI #MachineLearning #Tech #Innovation #FutureOfWork GitHub: github.com/Dujltqzv/Some-…

🔥 多Agent协作的"电话游戏"困境，终于有人解了 Anthropic做了一个实验：把一个编程任务拆成4个Agent，分别扮演规划者、实现者、测试者和审查者。结果发现——Agent之间花在协调上的token比干活本身还多。 这就是经典的"电话游戏"效应：每经过一次信息传递，质量就下降一分。每个Agent拿到的上下文都在退化，就像传话游戏里最后一个人听到的内容和第一个人说的完全不一样。 OpenAI在Agent SDK里加了handoffs原语，Google的ADK控制父Agent给子Agent传多少上下文。但这些都是设计时接线——你必须提前知道哪个Agent喂给哪个Agent。 问题是：现实中很多协作需求是临时冒出来的。比如线上服务报错率飙升，值班Agent查日志发现是某次部署导致的，接下来有人决定要画个图表对比上周基线。这个决策一分钟前还不存在，根本不会有预设的handoff。 Switch（Flint AI团队出品）的做法是把Agent和人都放进同一个聊天频道，任何人和任何Agent都可以直接协作，不需要预先接线。好处是： 1️⃣ 图表Agent加入频道时，能看到值班Agent的完整报告，不用重复查询 2️⃣ 被叫来做图表的人不用手动搬运上下文——第一个Agent的结论已经在频道里了 3️⃣ 如果第一个Agent发现没有回归问题，结果即时可见，团队不用等人工转达 关键是：人仍然掌控路由权，但不再需要当"人肉搬运工"。Switch支持Claude Code、OpenAI Codex、OpenCode等主流框架，也能对接Slack、Teams、Discord这些团队工具。 这可能是目前解决多Agent动态协作最优雅的方案了。你觉得Agent之间的信息传递该怎么设计？