1. 文章
1.1 AI代理的上下文工程：构建Manus的经验教训
Medium链接： Context Engineering for AI Agents: Lessons from Building Manus | by Yichao ‘Peak’ Ji | Medium
这篇文章是Peak.Ji在Manus的实践中总结的一些非常好的构建Agent的经验：
-
相对于押注于自己训练模型，Manus更加专注于上下文工程的优化。商用模型的迭代会快速让之前自己在模型上的努力化为泡影。
-
在设计上下文的时候，要围绕着KV存储进行设计。因为Agent会利用大量的上下文，但是输出简短的结构化内容（诸如函数调用等），这个in/out比例在他们测试的时候大概100:1。
-
能够缓存命中的上下文能够大量的节省成本，大概有10倍的差距。也能减少首个Token的生成时间，以便快速响应用户。
-
影响KV命中的几个关键实践：
- 保持上下文前缀稳定，不要在上下开头插入时间戳，特别是精确到秒的时间，（Ps：我觉得可以插入到天的时间）
- 使你的上下文只增加不修改，但要注意许多json解析库，在序列化的时候，不能保证每一次的顺序都是一致的。
- 在明确需要缓存的地方，增加缓存标记断点。这里要根据们不同的模型来确定，有些模型不支持自动前缀增量缓存。
-
在agent的上下文中，要控制工具的数量。除非绝对必要，要避免在迭代过程中动态添加或者移除工具。
- 大多数LLM中，工具定义序列化后在上下文的前部，在系统提示词之后，因此任何修改都会导致KV失效。
- LLM在阅读之前的上下文时，如果出现了上下文中不存在的工具，将会感到疑惑。
-
Manus使用上下文感知的状态机来管理工具可用性。它不是移除工具，而是在解码过程中掩蔽token的logits，以基于当前上下文阻止（或强制）选择某些动作。
-
函数调用通常有三种模式（我们将使用 NousResearch 的 Hermes 格式 作为示例）：
- 自动 – 模型可以选择调用或不调用函数。通过仅预填充回复前缀实现：
<|im_start|>assistant - 必需 – 模型必须调用函数，但选择不受约束。通过预填充到工具调用令牌实现：
<|im_start|>assistant<tool_call> - 指定 – 模型必须从特定子集中调用函数。通过预填充到函数名称的开头实现：
<|im_start|>assistant<tool_call>{"name": "browser_
- 自动 – 模型可以选择调用或不调用函数。通过仅预填充回复前缀实现：
-
Manus设计了具有一致性前缀的动作名称，所有与浏览器相关的工具都以
browser_开头，命令行工具以shell_开头。这使我们能够轻松确保代理在给定状态下只从特定工具组中进行选择而无需使用有状态的logits处理器。 -
使用文件系统作为上下文，如果上下文特别大，增加了成本，也导致模型性能下降，传统的做法是直接上下文截断或者压缩上下文，但你无法预测这些上下在未来是否会用到，以及压缩上下文会导致KV失效。所以Manus将上下文写入文件，Agent只要会按需写入或者读取文件，就可以保证上下不丢失，文件也可以按场景分类存储。
-
同时他们的上下压缩策略是可以恢复的，比如网页只保留URL，文件只保留文件路径等等。
-
在处理复杂任务的时候，需要先列一个todo.md文件，在并行任务的时候逐步更新它，勾选已完成的任务。这是一种注意力操控机制。
-
通过不断重写待办事项列表，Manus将其目标复述到上下文的末尾。这将全局计划推入模型的近期注意力范围内，避免了"丢失在中间"的问题，并减少了目标不一致。
-
对于大模型幻觉导致的错误，避免直接清理痕迹，重试，或者修改temperature。擦除痕迹会移除之前的错误证据，而改善Agent行为的有效方法：就是将错误保留在上下文中，当模型看到错误之后，就会去修改避免他。
-
少样本提示是提高LLM输出的常用技术。但在代理系统中，它可能会以微妙的方式适得其反。语言模型是优秀的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了类似的过去行动-观察对，模型将倾向于遵循该模式，即使这不再是最优的。
-
解决方法是增加多样性。Manus在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。
1.2 Wide Research：超越上下文窗口
1.3 AI能制作PowerPoint幻灯片吗？Manus如何利用上下文构建演示文稿
1.4 MCP Apps: Extending servers with interactive user interfaces | Model Context Protocol Blog
- 这是一个MCP-UI的提议，使用MCP当前的json-rpc协议支持
ui://的传输html，用于MCP返回的数据给用户展示，和从用户收集信息 - 初始只支持text/html，后续会在会支持更多，且在iframe中运行，需要得到用户的许可
- MCP-UI不只是UI规范，他会成为未来agentic应用的运行基础
相关Github：
MCP-UI-Org/mcp-ui
UI over MCP. Create next-gen UI experiences with the protocol and SDK!
2. 视频
2.1 Manus决定出售前最后的访谈：啊，这奇幻的2025年漂流啊…_哔哩哔哩_bilibili
2.2 Manus全球爆火，我们独家对话Manus创始人肖弘！_哔哩哔哩_bilibili
2.3 Manus被Meta收购，深度对谈创始人肖弘：我更希望做个小公司_哔哩哔哩_bilibili
- 地产中介通过 Manus 给他做了一个专属的找房PPT，让普通工作者也有了更大的潜力去做更专业的事。
- 在AI的帮助下，未来一两个人就可以做一番很大的事业。
- 当前很多场景都是给人类去使用的。未来更多场景是通过API去给agent的使用。未来Agent与软件的交互，人类将不再参与。
- Agent很重要的是先制作一个规划，然后根据当前的规划一步一步的去做。同时基于当前这一步的结果和之前的规划进行反思。
- Agent有两个非常重要的能力，一个是长程规划能力，一个是逐步执行能力。这两个能力是传统Chatbot不太具有的。
- 机器人替代劳动工作者，Agent替代知识工作者。
- 传统的金融，咨询，律师这些行业受到Agent的影响是会比较大的。Agent对知识工作者应将会带来比较大的变化。
- 浏览器作为一个传统传工具，AI浏览器Agent的将会与人类去抢电脑使用。这种操作体验是比较怪的。同时，浏览器作为一个传统的品类，除非你有很大的创新，人类才会去更换浏览器。
- token的成本今天很贵，长期来看一定会便宜。互联网用户其实是越来越贵的。早期用户是比较善于探索的。当这个产品逐渐成熟了之后，用户是不愿意去寻找新的产品。或者一些比较成熟的产品将会通过广告将用户给获取过来。从而推高整个行业的获客成本。
- 在AI时代，创业思考的起点是技术；而在传统的互联网时代，思考的起点更多是用户场景。在AI时代，更重要是对技术的理解，以及这些技术在人们已经被验证或者想要的需求上，今天的技术怎么去解决这些问题？
- 真正AI原生的人，可能所有工作都先AI一下。
3. 项目
daytonaio/daytona
Daytona is a Secure and Elastic Infrastructure for Running AI-Generated Code
4. 发现
4.1 ListenHub – 解说万物，一键生成视频、播客、PPT
4.2 Megi — 将线性对话，生长为思考的知识树 - 少数派
4.3 使用 Hugo + GitHub + Decap CMS + Cloudflare Pages 构建支持自定义域名的无服务器博客步骤 – iXam
5. 资源
5.1 Agentic Design Patterns | 《Agentic Design Patterns》中文翻译项目 - 系统介绍 AI Agent 系统的各种设计模式
5.2 国内使用gemni
如果国内使用报上面的错话，可以下面的url进入就可以了
https://gemini.google.com/gems/create?hl=en-US&pli=1
5.3 VibeVibe
VibeVibe 网站强调不需要任何编程背景，即使是完全的新手，也能通过平台提供的资源和手把手的指导
5.4 1.3 Claude Code与其他AI编程工具的对比 | Claude Code深度教程，免费从入门到精通
专为开发者打造的终极文档指南。从环境配置到构建自定义 AI 智能体，这套免费教程将帮助您掌握下一代编程工具，提升 3 倍开发效率。
评论