除了RAG，还可以考虑知识图谱。把领域知识构建成图谱，每次只提取与当前问题相关的子图作为上下文，能更精确地注入知识，减少冗余信息，降低Context Window压力。不过知识图谱的构建和维护成本比较高，需要专业的知识工程师。
可以参考软件工程里的模块化设计思想，将Skills文件组织成层级结构，比如按照领域、功能、复杂度等维度进行分类。这样Agent可以先在高层级进行粗略的检索，然后再逐步深入到更细粒度的层级，最终找到所需的Skill。
Agent Skills的主要优势在于可复用性和渐进式披露。可以把复杂的领域知识、操作规范、最佳实践封装成独立的Skills文件包，使得这个能力可以在不同Agent中快速复用。在智能家居场景下，可以使用Skills文件包进行快速复用。
这个45%更像是一个经验值，告诉我们不要迷信“人多力量大”。当单Agent已经能解决大部分问题时，增加Agent数量可能反而会引入更多的复杂性和通信成本。 在实际应用中，我会把这个阈值作为一个参考，结合具体业务场景进行评估。比如，如果业务对准确率要求很高，那么即使单Agent的成功率超过45%，也可以考虑引入Multi-Agent来提高准确率。但如果业务对成本比较敏感，那么就应该尽量避免使用Multi-Agent，而是通过优化单Agent来满足需求。
其实，我觉得可以借鉴人类开会做决策的方式。每次讨论完一个议题，就形成一个明确的结论，这个结论就相当于一个“锚点”，后续的讨论都围绕这个锚点展开，而之前的上下文就可以适当遗忘。这样Agent就不会被过多的历史信息干扰，始终聚焦于当前的核心目标。
这个45%的阈值肯定不是绝对的。我认为它更像是一个经验法则，提醒我们不要盲目堆砌Agent。在某些对准确性要求极高的领域，比如医疗诊断，即使Single Agent的成功率达到90%，我们可能仍然需要Multi-Agent来做交叉验证，以降低误诊率。而在一些容错率较高的场景，比如创意写作，可能30%的成功率就足够了。
我觉得任务的复杂度也会影响这个阈值。对于结构化的、逻辑清晰的任务，Single Agent可能很容易达到较高的成功率，增加Agent的意义不大。但对于那些需要发散性思维和探索性尝试的任务，即使Single Agent的成功率很低，Multi-Agent也可能带来意想不到的突破。
我有个更“玄学”的想法：让Agent们学习“谈判”技巧。在修改共享状态之前，Agent们先进行协商，明确各自的修改范围和目标，达成一致后再进行修改。这就像几个程序员一起修改代码，先开个会明确分工，避免互相覆盖。
关于上下文管理，我想到的是引入外部知识图谱。Agent可以将对话中抽取出的关键信息存入知识图谱，需要时再从图谱中检索相关内容，而不是完全依赖上下文窗口。这样一来，上下文窗口就可以专注于当前的任务，而历史信息则交由知识图谱来管理，大大减轻了Agent的记忆负担。
这个问题确实是Agent Teams落地的关键！我觉得可以引入“锁”机制，就像多线程编程那样。当一个Agent需要修改共享状态时，先获取锁，修改完成后释放锁，确保同一时间只有一个Agent可以修改共享状态。当然，锁的粒度需要仔细设计，太粗会影响并行效率，太细又容易造成死锁。
这个问题问得好！除了文章提到的上下文压缩和滑动窗口，我认为可以试试“记忆蒸馏”。就像知识蒸馏把大模型的知识转移到小模型一样，我们可以周期性地让Agent用它当前的理解来总结之前的对话，然后只保留这个精简的总结，相当于给Agent做个“阶段性考试”，考完就忘了之前的细节，只记住最重要的结论，这样既能减轻上下文负担，又能保持连贯性。
抛开具体数字，这个结论背后的逻辑是“边际效应递减”。当一个问题的解决方案已经比较成熟时，投入更多的资源带来的收益会越来越小。所以，在决定是否引入Multi-Agent时，我们需要仔细评估当前方案的潜力，以及增加Agent可能带来的额外价值。
可以考虑使用“乐观锁”策略。每个Agent在修改共享状态之前，先记录当前状态的版本号，修改完成后提交时，检查版本号是否发生变化。如果版本号不一致，说明其他Agent已经修改了状态，需要重新获取最新状态并再次尝试修改。这种方式可以减少锁的竞争，提高并行效率。