即刻App年轻人的同好社区
下载
Manus 联合创始人兼首席技术官 Yichao “Peak” Ji 在 Manus 发表了一篇blog，分享他们在构建AI Agent 过程中的经验教训，深入探讨了“上下文工程”（Context Engineering）的技术实践。以下是原文翻译。
AI智能体的上下文工程：构建Manus的经验教训by Yichao “Peak” Ji 2025/07/18
在 Manus 项目之初，我和我的团队面临一个关键决策：我们应该使用开源基础模型来训练一个端到端的智能体模型，还是在顶尖模型的“上下文中学习”（in-context learning）能力之上构建一个智能体？
在我从事 NLP 的第一个十年里，我们并没有这样的选择。在遥远的 BERT 时代（是的，已经七年了），模型必须经过微调和评估，才能迁移到新任务上。这个过程每次迭代通常需要数周，尽管那时的模型比今天的 LLM 小得多。对于快速迭代的应用，尤其是在找到产品市场契合点（PMF）之前，如此缓慢的反馈循环是致命的。这是我上一次创业的惨痛教训，当时我为开放信息提取和语义搜索从零开始训练模型。然后 GPT-3 和 Flan-T5 出现了，我的自研模型一夜之间变得无关紧要。讽刺的是，正是这些模型标志着在上下文学习的开始以及一条全新的前进道路。
这个来之不易的教训让选择变得清晰：Manus 将赌注押在上下文工程上。这使我们能以小时为单位发布改进，而不是数周，并使我们的产品与底层模型正交：如果模型的进步是涨潮，我们希望 Manus 是船，而不是固定在海床上的柱子。尽管如此，上下文工程远非一帆风顺，它是一门实验科学。我们已经重建了我们的智能体框架四次，每次都是在发现塑造上下文的更好方法之后。我们亲切地将这个架构搜索、提示调整和经验猜测的手动过程称为“随机毕业生下降”（Stochastic Graduate Descent）。它不优雅，但它有效。这篇文章分享了我们通过自己的“SGD”达到的局部最优解。如果你正在构建自己的 AI 智能体，我希望这些原则能帮助你更快地收敛。
围绕 KV-Cache 进行设计
如果我必须只选择一个指标，我会说 KV-cache 命中率是生产阶段 AI 智能体最重要的单一指标。它直接影响延迟和成本。要理解为什么，让我们看看一个典型智能体的运作方式：
在收到用户输入后，智能体通过一系列工具使用来完成任务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。该动作在环境中执行（例如 Manus 的虚拟机沙箱）以产生一个观察结果。动作和观察结果被附加到上下文中，形成下一次迭代的输入。这个循环持续到任务完成。
可以想象，上下文每一步都在增长，而输出（通常是结构化的函数调用）保持相对较短。这使得智能体中预填充和解码的比例与聊天机器人相比高度倾斜。例如，在 Manus 中，平均输入输出令牌比例约为 100:1。
幸运的是，具有相同前缀的上下文可以利用 KV-cache，这大大减少了首个令牌生成时间（TTFT）和推理成本。无论你是使用自托管模型还是调用推理 API。我们谈论的不是小节省：例如，使用 Claude Sonnet，缓存的输入令牌成本为 0.30 美元/百万令牌，而未缓存的成本为 3 美元/百万令牌，成本相差 10 倍。
从上下文工程的角度来看，提高 KV-cache 命中率涉及几个关键实践：
1.保持你的提示前缀稳定。由于 LLM 的自回归特性，即使是单个令牌的差异也会使从该令牌开始的缓存失效。一个常见的错误是在系统提示的开头包含时间戳，特别是精确到秒的时间戳。当然，它能让模型告诉你当前时间，但它也扼杀了你的缓存命中率。
2.使你的上下文仅追加。避免修改以前的动作或观察。确保你的序列化是确定性的。许多编程语言和库在序列化 JSON 对象时不保证稳定的键顺序，这会悄悄地破坏缓存。
3.在需要时明确标记缓存断点。一些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。在分配这些断点时，要考虑潜在的缓存过期，并至少确保断点包含系统提示的结尾。
此外，如果你使用像 vLLM 这样的框架自托管模型，请确保启用了前缀/提示缓存，并使用会话 ID 等技术在分布式工作节点间一致地路由请求。
掩码，而非移除
随着你的智能体承担更多能力，其动作空间自然变得更复杂。简而言之，工具数量爆炸式增长。最近 MCP 的流行更是火上浇油。如果你允许用户可配置的工具，相信我：总会有人将数百个神秘的工具插入你精心策划的动作空间。结果，模型更可能选择错误的动作或采取低效路径。简而言之，你全副武装的智能体变笨了。
一个自然的反应是设计一个动态的动作空间，也许使用类似 RAG 的方式按需加载工具。我们在 Manus 中也尝试过。但我们的实验表明一个明确的规则：除非绝对必要，否则避免在迭代中动态添加或移除工具。主要有两个原因：
1. 在大多数 LLM 中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此，任何更改都会使所有后续动作和观察的 KV-cache 失效。
2. 当以前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。没有约束解码，这通常会导致模式违规或幻觉动作。
为了解决这个问题同时改善动作选择，Manus 使用上下文感知的状态机来管理工具可用性。它不是移除工具，而是在解码期间掩码令牌 logits，以根据当前上下文阻止（或强制）选择某些动作。
在实践中，大多数模型提供商和推理框架支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间。通常有三种函数调用模式（我们以 NousResearch 的 Hermes 格式为例）：1. 自动 – 模型可以选择调用函数或不调用。通过仅预填充回复前缀实现：`<|im_start|>assistant`
2. 必需 – 模型必须调用一个函数，但选择不受限制。通过预填充到工具调用令牌实现：`<|im_start|>assistant<tool_call>`
3. 指定 – 模型必须从特定子集中调用一个函数。通过预填充到函数名称的开头实现：`<|im_start|>assistant<tool_call>{"name": "browser_`
使用这种方法，我们通过直接掩码令牌 logits 来约束动作选择。例如，当用户提供新输入时，Manus 必须立即回复而不是采取行动。我们还特意设计了具有一致前缀的动作名称——例如，所有浏览器相关的工具都以 `browser_` 开头，命令行工具以 `shell_` 开头。这使我们能够轻松地强制智能体在给定状态下仅从某个工具组中选择，而无需使用有状态的 logits 处理器。
这些设计有助于确保 Manus 智能体即使在模型驱动的架构下也能循环保持稳定。
使用文件系统作为上下文
现代顶尖 LLM 现在提供 128K 甚至更多的令牌上下文窗口。但在现实世界的智能体场景中，这通常不够，有时甚至是一种负担。有三个常见的痛点：
1. 观察结果可能非常巨大，特别是当智能体与非结构化数据如网页或 PDF 交互时。很容易超出上下文限制。
2. 模型性能在超过一定上下文长度后往往会下降，即使窗口技术上支持。
3. 长输入很昂贵，即使有前缀缓存。你仍然为传输和预填充每个令牌付费。
为了解决这个问题，许多智能体系统实现了上下文截断或压缩策略。但过于激进的压缩不可避免地导致信息丢失。问题是根本性的：智能体本质上必须根据所有先前的状态预测下一个动作，因为你无法可靠地预测哪个观察结果在十步后可能变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。
这就是为什么我们将文件系统视为 Manus 中的终极上下文：大小无限，本质上是持久的，并且可由智能体自己直接操作。模型学会按需写入和读取文件，使用文件系统不仅作为存储，而且作为结构化的外化记忆。
我们的压缩策略总是被设计为可恢复的。例如，只要保留 URL，网页内容就可以从上下文中丢弃，只要其路径在沙箱中可用，文档内容就可以省略。这使得 Manus 可以在不永久丢失信息的情况下缩短上下文长度。
在开发此功能时，我发现自己想象着让状态空间模型（SSM）在智能体环境中有效工作需要什么。与 Transformer 不同，SSM 缺乏完全的注意力，难以处理长程向后依赖。但如果它们能掌握基于文件的记忆，即将长期状态外化而不是保留在上下文中，那么它们的速度和效率可能会解锁一类新的智能体。智能体 SSM 可能是神经图灵机的真正继承者。
通过重复操控注意力
如果你使用过 Manus，你可能已经注意到一些奇怪的事情：在处理复杂任务时，它倾向于创建一个 `todo.md` 文件并随着任务进展逐步更新它，勾选已完成的项目。
这不仅仅是可爱的行为，这是一种深思熟虑的操控注意力的机制。
Manus 中的一个典型任务平均需要大约 50 次工具调用。这是一个很长的循环，而且由于 Manus 依赖 LLM 进行决策，它很容易偏离主题或忘记早期的目标，特别是在长上下文或复杂任务中。
通过不断重写待办事项列表，Manus 将其目标重复到上下文的末尾。这将全局计划推入模型的近期注意力范围，避免"在中间迷失"问题并减少目标错位。实际上，它是在使用自然语言来偏置其自身对任务目标的关注而无需特殊的架构更改。
保留错误的东西
智能体会犯错。这不是一个 bug，这是现实。语言模型会产生幻觉，环境会返回错误，外部工具会行为不当，意外的边缘情况会一直出现。在多步骤任务中，失败不是例外，它是循环的一部分。
然而，一个常见的冲动是隐藏这些错误：清理痕迹，重试动作，或重置模型的状态并将其留给神奇的"温度"。这感觉更安全、更可控。但它有代价：抹去失败就移除了证据。而没有证据，模型无法适应。
在我们的经验中，改善智能体行为最有效的方法之一出奇地简单：在上下文中保留错误的转折。当模型看到一个失败的动作以及由此产生的观察或堆栈跟踪，它会隐式地更新其内部信念。这将它的先验从相似的动作移开，减少重复同样错误的机会。事实上，我们认为错误恢复是真正智能体行为的最清晰指标之一。然而，在大多数学术工作和公共基准中，它仍然代表不足，这些基准通常关注理想条件下的任务成功。
不要被 Few-Shot 束缚
Few-shot 提示是改善 LLM 输出的常用技术。但在智能体系统中，它可能以微妙的方式适得其反。
语言模型是出色的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了相似的过去动作-观察对，模型将倾向于遵循该模式，即使它不再是最佳选择。
这在涉及重复决策或动作的任务中可能很危险。例如，当使用 Manus 帮助审查一批 20 份简历时，智能体经常陷入一种重复相似的动作，仅仅因为那是它在上下文中看到的，这会导致漂移、过度泛化，或有时产生幻觉。
解决方法是增加多样性。Manus 在动作和观察中引入少量结构化变化：不同的序列化模板、替代措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。换句话说，不要让自己陷入 few-shot 的窠臼。你的上下文越统一，你的智能体就越脆弱。
结论
上下文工程仍然是一门新兴科学，但对于智能体系统来说，它已经必不可少。模型可能越来越强大、越来越快、越来越便宜，但没有任何原始能力可以取代记忆、环境和反馈的需求。你如何塑造上下文最终定义了你的智能体如何表现：它运行多快，恢复得多好，以及扩展多远。
在 Manus，我们通过反复重写、死胡同和数百万用户的真实世界测试学到了这些经验教训。我们在这里分享的都不是普适真理，但这些是对我们有效的模式。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的工作。
智能体的未来将一次一个上下文地构建。好好地工程化它们。
AI智能体的上下文工程：构建Manus的经验教训by Yichao “Peak” Ji 2025/07/18
在 Manus 项目之初，我和我的团队面临一个关键决策：我们应该使用开源基础模型来训练一个端到端的智能体模型，还是在顶尖模型的“上下文中学习”（in-context learning）能力之上构建一个智能体？
在我从事 NLP 的第一个十年里，我们并没有这样的选择。在遥远的 BERT 时代（是的，已经七年了），模型必须经过微调和评估，才能迁移到新任务上。这个过程每次迭代通常需要数周，尽管那时的模型比今天的 LLM 小得多。对于快速迭代的应用，尤其是在找到产品市场契合点（PMF）之前，如此缓慢的反馈循环是致命的。这是我上一次创业的惨痛教训，当时我为开放信息提取和语义搜索从零开始训练模型。然后 GPT-3 和 Flan-T5 出现了，我的自研模型一夜之间变得无关紧要。讽刺的是，正是这些模型标志着在上下文学习的开始以及一条全新的前进道路。
这个来之不易的教训让选择变得清晰：Manus 将赌注押在上下文工程上。这使我们能以小时为单位发布改进，而不是数周，并使我们的产品与底层模型正交：如果模型的进步是涨潮，我们希望 Manus 是船，而不是固定在海床上的柱子。尽管如此，上下文工程远非一帆风顺，它是一门实验科学。我们已经重建了我们的智能体框架四次，每次都是在发现塑造上下文的更好方法之后。我们亲切地将这个架构搜索、提示调整和经验猜测的手动过程称为“随机毕业生下降”（Stochastic Graduate Descent）。它不优雅，但它有效。这篇文章分享了我们通过自己的“SGD”达到的局部最优解。如果你正在构建自己的 AI 智能体，我希望这些原则能帮助你更快地收敛。
围绕 KV-Cache 进行设计
如果我必须只选择一个指标，我会说 KV-cache 命中率是生产阶段 AI 智能体最重要的单一指标。它直接影响延迟和成本。要理解为什么，让我们看看一个典型智能体的运作方式：
在收到用户输入后，智能体通过一系列工具使用来完成任务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。该动作在环境中执行（例如 Manus 的虚拟机沙箱）以产生一个观察结果。动作和观察结果被附加到上下文中，形成下一次迭代的输入。这个循环持续到任务完成。
可以想象，上下文每一步都在增长，而输出（通常是结构化的函数调用）保持相对较短。这使得智能体中预填充和解码的比例与聊天机器人相比高度倾斜。例如，在 Manus 中，平均输入输出令牌比例约为 100:1。
幸运的是，具有相同前缀的上下文可以利用 KV-cache，这大大减少了首个令牌生成时间（TTFT）和推理成本。无论你是使用自托管模型还是调用推理 API。我们谈论的不是小节省：例如，使用 Claude Sonnet，缓存的输入令牌成本为 0.30 美元/百万令牌，而未缓存的成本为 3 美元/百万令牌，成本相差 10 倍。
从上下文工程的角度来看，提高 KV-cache 命中率涉及几个关键实践：
1.保持你的提示前缀稳定。由于 LLM 的自回归特性，即使是单个令牌的差异也会使从该令牌开始的缓存失效。一个常见的错误是在系统提示的开头包含时间戳，特别是精确到秒的时间戳。当然，它能让模型告诉你当前时间，但它也扼杀了你的缓存命中率。
2.使你的上下文仅追加。避免修改以前的动作或观察。确保你的序列化是确定性的。许多编程语言和库在序列化 JSON 对象时不保证稳定的键顺序，这会悄悄地破坏缓存。
3.在需要时明确标记缓存断点。一些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。在分配这些断点时，要考虑潜在的缓存过期，并至少确保断点包含系统提示的结尾。
此外，如果你使用像 vLLM 这样的框架自托管模型，请确保启用了前缀/提示缓存，并使用会话 ID 等技术在分布式工作节点间一致地路由请求。
掩码，而非移除
随着你的智能体承担更多能力，其动作空间自然变得更复杂。简而言之，工具数量爆炸式增长。最近 MCP 的流行更是火上浇油。如果你允许用户可配置的工具，相信我：总会有人将数百个神秘的工具插入你精心策划的动作空间。结果，模型更可能选择错误的动作或采取低效路径。简而言之，你全副武装的智能体变笨了。
一个自然的反应是设计一个动态的动作空间，也许使用类似 RAG 的方式按需加载工具。我们在 Manus 中也尝试过。但我们的实验表明一个明确的规则：除非绝对必要，否则避免在迭代中动态添加或移除工具。主要有两个原因：
1. 在大多数 LLM 中，工具定义在序列化后位于上下文的前部，通常在系统提示之前或之后。因此，任何更改都会使所有后续动作和观察的 KV-cache 失效。
2. 当以前的动作和观察仍然引用当前上下文中不再定义的工具时，模型会感到困惑。没有约束解码，这通常会导致模式违规或幻觉动作。
为了解决这个问题同时改善动作选择，Manus 使用上下文感知的状态机来管理工具可用性。它不是移除工具，而是在解码期间掩码令牌 logits，以根据当前上下文阻止（或强制）选择某些动作。
在实践中，大多数模型提供商和推理框架支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间。通常有三种函数调用模式（我们以 NousResearch 的 Hermes 格式为例）：1. 自动 – 模型可以选择调用函数或不调用。通过仅预填充回复前缀实现：`<|im_start|>assistant`
2. 必需 – 模型必须调用一个函数，但选择不受限制。通过预填充到工具调用令牌实现：`<|im_start|>assistant<tool_call>`
3. 指定 – 模型必须从特定子集中调用一个函数。通过预填充到函数名称的开头实现：`<|im_start|>assistant<tool_call>{"name": "browser_`
使用这种方法，我们通过直接掩码令牌 logits 来约束动作选择。例如，当用户提供新输入时，Manus 必须立即回复而不是采取行动。我们还特意设计了具有一致前缀的动作名称——例如，所有浏览器相关的工具都以 `browser_` 开头，命令行工具以 `shell_` 开头。这使我们能够轻松地强制智能体在给定状态下仅从某个工具组中选择，而无需使用有状态的 logits 处理器。
这些设计有助于确保 Manus 智能体即使在模型驱动的架构下也能循环保持稳定。
使用文件系统作为上下文
现代顶尖 LLM 现在提供 128K 甚至更多的令牌上下文窗口。但在现实世界的智能体场景中，这通常不够，有时甚至是一种负担。有三个常见的痛点：
1. 观察结果可能非常巨大，特别是当智能体与非结构化数据如网页或 PDF 交互时。很容易超出上下文限制。
2. 模型性能在超过一定上下文长度后往往会下降，即使窗口技术上支持。
3. 长输入很昂贵，即使有前缀缓存。你仍然为传输和预填充每个令牌付费。
为了解决这个问题，许多智能体系统实现了上下文截断或压缩策略。但过于激进的压缩不可避免地导致信息丢失。问题是根本性的：智能体本质上必须根据所有先前的状态预测下一个动作，因为你无法可靠地预测哪个观察结果在十步后可能变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。
这就是为什么我们将文件系统视为 Manus 中的终极上下文：大小无限，本质上是持久的，并且可由智能体自己直接操作。模型学会按需写入和读取文件，使用文件系统不仅作为存储，而且作为结构化的外化记忆。
我们的压缩策略总是被设计为可恢复的。例如，只要保留 URL，网页内容就可以从上下文中丢弃，只要其路径在沙箱中可用，文档内容就可以省略。这使得 Manus 可以在不永久丢失信息的情况下缩短上下文长度。
在开发此功能时，我发现自己想象着让状态空间模型（SSM）在智能体环境中有效工作需要什么。与 Transformer 不同，SSM 缺乏完全的注意力，难以处理长程向后依赖。但如果它们能掌握基于文件的记忆，即将长期状态外化而不是保留在上下文中，那么它们的速度和效率可能会解锁一类新的智能体。智能体 SSM 可能是神经图灵机的真正继承者。
通过重复操控注意力
如果你使用过 Manus，你可能已经注意到一些奇怪的事情：在处理复杂任务时，它倾向于创建一个 `todo.md` 文件并随着任务进展逐步更新它，勾选已完成的项目。
这不仅仅是可爱的行为，这是一种深思熟虑的操控注意力的机制。
Manus 中的一个典型任务平均需要大约 50 次工具调用。这是一个很长的循环，而且由于 Manus 依赖 LLM 进行决策，它很容易偏离主题或忘记早期的目标，特别是在长上下文或复杂任务中。
通过不断重写待办事项列表，Manus 将其目标重复到上下文的末尾。这将全局计划推入模型的近期注意力范围，避免"在中间迷失"问题并减少目标错位。实际上，它是在使用自然语言来偏置其自身对任务目标的关注而无需特殊的架构更改。
保留错误的东西
智能体会犯错。这不是一个 bug，这是现实。语言模型会产生幻觉，环境会返回错误，外部工具会行为不当，意外的边缘情况会一直出现。在多步骤任务中，失败不是例外，它是循环的一部分。
然而，一个常见的冲动是隐藏这些错误：清理痕迹，重试动作，或重置模型的状态并将其留给神奇的"温度"。这感觉更安全、更可控。但它有代价：抹去失败就移除了证据。而没有证据，模型无法适应。
在我们的经验中，改善智能体行为最有效的方法之一出奇地简单：在上下文中保留错误的转折。当模型看到一个失败的动作以及由此产生的观察或堆栈跟踪，它会隐式地更新其内部信念。这将它的先验从相似的动作移开，减少重复同样错误的机会。事实上，我们认为错误恢复是真正智能体行为的最清晰指标之一。然而，在大多数学术工作和公共基准中，它仍然代表不足，这些基准通常关注理想条件下的任务成功。
不要被 Few-Shot 束缚
Few-shot 提示是改善 LLM 输出的常用技术。但在智能体系统中，它可能以微妙的方式适得其反。
语言模型是出色的模仿者；它们模仿上下文中的行为模式。如果你的上下文充满了相似的过去动作-观察对，模型将倾向于遵循该模式，即使它不再是最佳选择。
这在涉及重复决策或动作的任务中可能很危险。例如，当使用 Manus 帮助审查一批 20 份简历时，智能体经常陷入一种重复相似的动作，仅仅因为那是它在上下文中看到的，这会导致漂移、过度泛化，或有时产生幻觉。
解决方法是增加多样性。Manus 在动作和观察中引入少量结构化变化：不同的序列化模板、替代措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。换句话说，不要让自己陷入 few-shot 的窠臼。你的上下文越统一，你的智能体就越脆弱。
结论
上下文工程仍然是一门新兴科学，但对于智能体系统来说，它已经必不可少。模型可能越来越强大、越来越快、越来越便宜，但没有任何原始能力可以取代记忆、环境和反馈的需求。你如何塑造上下文最终定义了你的智能体如何表现：它运行多快，恢复得多好，以及扩展多远。
在 Manus，我们通过反复重写、死胡同和数百万用户的真实世界测试学到了这些经验教训。我们在这里分享的都不是普适真理，但这些是对我们有效的模式。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的工作。
智能体的未来将一次一个上下文地构建。好好地工程化它们。
3 00
为了在Cursor Meetup广州站与大家更好地交流，我们为Cursor做了个一键调用的Mcp Store。通过开源项目Context Space能够在Cursor 里一键调用第三方数据源和工具。
开发者们使用Context Space可以省掉反复填写 mcp.json 配置文件的繁琐流程，未来我们会内置工具自动发现和 Memory 管理的能力。
开发者们使用Context Space可以省掉反复填写 mcp.json 配置文件的繁琐流程，未来我们会内置工具自动发现和 Memory 管理的能力。
1 00
在阿里内网看到这篇分享贴后，我立刻去Github Star了这个开源项目。
我一直都想做一个AI应用，但是因为要调用很多外部服务和数据，往往卡在接入API这一步，经常调试很多次都报错。
Context Space这个开源项目彻底简化了复杂的MCP配置流程，开发者不需要在本地运行任何服务，可以让Cursor和Claude Code这样的IDE一件键连接到超过14个Integrations.
对于我这种独立开发者，用了Context Space，再也不用处理复杂的OAuth流程和权限管理，只要专注在产品设计和业务逻辑本身。
如果你也在为AI集成、数据安全、平台拓展发愁，不妨试试这个项目。Github项目地址github.com
#AI工作流 #AI的神奇用法
我一直都想做一个AI应用，但是因为要调用很多外部服务和数据，往往卡在接入API这一步，经常调试很多次都报错。
Context Space这个开源项目彻底简化了复杂的MCP配置流程，开发者不需要在本地运行任何服务，可以让Cursor和Claude Code这样的IDE一件键连接到超过14个Integrations.
对于我这种独立开发者，用了Context Space，再也不用处理复杂的OAuth流程和权限管理，只要专注在产品设计和业务逻辑本身。
如果你也在为AI集成、数据安全、平台拓展发愁，不妨试试这个项目。Github项目地址github.com
#AI工作流 #AI的神奇用法
4 01
0代码基础，用Chatgpt+Cursor开发6个iOS App和两个网站后，我相信所有人都能用AI开发自己的app和网站，所以我做了个开源项目 Vibe Coding Guide，这是一份人人都能学会的自然语言编程指南。
借助AI，人人都可以成为独立开发者。正因为亲身体验了 AI 编程的强大力量，我创建了这个开源项目。欢迎有Vibe Coding经验的网友，提PR分享你的AI编程体验。
Vibe Coding Guide是一个人人都能学会的自然语言编程指南。作为零基础AI编程教程，考虑到易读性，我在Readme里解释概念和基础流程，其他文档按照IDEs and Tools, LLMs, Prompts, My experience汇总。
如果你想了解具体如何实践，可以直接看My experience，里面包含我用Xcode+Chatgpt开发6个ios app的全流程，以及用Cursor开发网站的全流程。
希望每个有想法的人都能借助 AI 创造属于自己的产品，让技术不再是创意实现的门槛。
项目地址github.com
借助AI，人人都可以成为独立开发者。正因为亲身体验了 AI 编程的强大力量，我创建了这个开源项目。欢迎有Vibe Coding经验的网友，提PR分享你的AI编程体验。
Vibe Coding Guide是一个人人都能学会的自然语言编程指南。作为零基础AI编程教程，考虑到易读性，我在Readme里解释概念和基础流程，其他文档按照IDEs and Tools, LLMs, Prompts, My experience汇总。
如果你想了解具体如何实践，可以直接看My experience，里面包含我用Xcode+Chatgpt开发6个ios app的全流程，以及用Cursor开发网站的全流程。
希望每个有想法的人都能借助 AI 创造属于自己的产品，让技术不再是创意实现的门槛。
项目地址github.com
9 03
无论发什么Twitter曝光都不过百，有人知道怎么冷启动么？🥺@歸藏
15 100
写了个开源爬虫小工具 ，用来精准挖墙脚。众所周知我最近的小目标是Context Space这个开源项目获得10k star，于是我就开始爬类似的github项目，看看有哪些人star或者fork了这些仓库。
这些人是同行帮我筛选过的目标用户，精准匹配我的项目受众人群。爬到这些人的名单以后，我再通过各种方式联系他们试用我的项目。
目前只搞定了github，寻有志之士帮忙爬Twitter和其他平台，这是个后端部署不太稳定的开源项目，大家最好star以后本地调用😗
Github项目地址github.com
这些人是同行帮我筛选过的目标用户，精准匹配我的项目受众人群。爬到这些人的名单以后，我再通过各种方式联系他们试用我的项目。
目前只搞定了github，寻有志之士帮忙爬Twitter和其他平台，这是个后端部署不太稳定的开源项目，大家最好star以后本地调用😗
Github项目地址github.com
5 21
我们把超过30000行代码的Context Engineering项目开源了~所有人都可以免费用Context Space构建 AI 应用，无需从零搭建上下文系统，也不用再担心prompt 调优。
Context Space已经接入GitHub、Slack、Notion、Airtable 等主流工具，内置记忆、检索、个性化和 OAuth 安全机制，即插即用。
在GitHub上Star & Fork就可以直接clone代码，项目地址👉 github.com
Context Space已经接入GitHub、Slack、Notion、Airtable 等主流工具，内置记忆、检索、个性化和 OAuth 安全机制，即插即用。
在GitHub上Star & Fork就可以直接clone代码，项目地址👉 github.com
5 00
我们把超过三万行的Context Space代码开源了，所有人都能用我们的代码轻松搭建具备上下文理解能力的AI应用。
AI时代技术平权，是我们团队的核心理念，所以Context Space我们从开发者的角度做了许多优化
✅ 降低开发门槛：小白也能用，无需从 0 搭建复杂的上下文管理系统
Context Space上线了十几个即插即用的服务集成，开发者常用的 GitHub、Slack、Notion、HubSpot等都可以一步直连。同时基于MCP协议提供标准化的上下文接口，支持 REST API，适合各种编程语言和平台。
✅ 提高开发效率：无需硬编码、重复对接
Context Space帮你自动处理 OAuth 授权和凭据管理，比如集成 HashiCorp Vault等等。具备内置缓存、持久化机制，可跨会话存储和检索用户上下文。采用模块化架构，便于开发者们二次开发和自定义扩展。
✅ 真正为生产环境设计，从原型到生产都能搞定
Context Space支持 Docker、Kubernetes 等部署方式，内置日志监控、指标追踪、token 轮换、安全审计等特性，支持多用户上下文隔离。
✅ 适用于不同能力水平的开发者
新手开发者或者Vibe Coding可以用Context Space的现成模块搭建 Chatbot、Agent 系统，有经验的开发者可以利用 REST 接口、SDK 接入自己的模型或服务，架构师可以自定义语义检索、上下文压缩、持久内存结构。
⭐️ 目前Github已完成开源，项目地址github.com，希望大家和我们一起共建开源社区，完善AI生态，欢迎Star我们的项目~
AI时代技术平权，是我们团队的核心理念，所以Context Space我们从开发者的角度做了许多优化
✅ 降低开发门槛：小白也能用，无需从 0 搭建复杂的上下文管理系统
Context Space上线了十几个即插即用的服务集成，开发者常用的 GitHub、Slack、Notion、HubSpot等都可以一步直连。同时基于MCP协议提供标准化的上下文接口，支持 REST API，适合各种编程语言和平台。
✅ 提高开发效率：无需硬编码、重复对接
Context Space帮你自动处理 OAuth 授权和凭据管理，比如集成 HashiCorp Vault等等。具备内置缓存、持久化机制，可跨会话存储和检索用户上下文。采用模块化架构，便于开发者们二次开发和自定义扩展。
✅ 真正为生产环境设计，从原型到生产都能搞定
Context Space支持 Docker、Kubernetes 等部署方式，内置日志监控、指标追踪、token 轮换、安全审计等特性，支持多用户上下文隔离。
✅ 适用于不同能力水平的开发者
新手开发者或者Vibe Coding可以用Context Space的现成模块搭建 Chatbot、Agent 系统，有经验的开发者可以利用 REST 接口、SDK 接入自己的模型或服务，架构师可以自定义语义检索、上下文压缩、持久内存结构。
⭐️ 目前Github已完成开源，项目地址github.com，希望大家和我们一起共建开源社区，完善AI生态，欢迎Star我们的项目~
40 123
有人想一起做播客吗？最近听多了播客，于是也想做一档有意思的播客。倾向的播客形式是双人对谈或者多人访谈，寻找几位合作者作为固定嘉宾，每期关于一两个话题展开对话。
固定嘉宾不用每期参加，我们可以轮流参与录制，话题倾向于AI、金融、科技、职场、文化、故事等，如果你有熟悉或者感兴趣的其他话题我们也可以商量~
如果邀请到飞行嘉宾，可以采用多人访谈的形式。我的朋友圈有几千人，涵盖金融、互联网、传媒等行业。播客数据好的话，我会鼓起勇气邀请朋友做飞行嘉宾。希望你交友广泛，能够一起邀请飞行嘉宾参与，让播客内容更多元。
我喜欢有观点也有态度的节目，比如今夜不设防，栋笃笑，锵锵三人行，The Tonight Show Starring Jimmy Fallon，Saturday Night Live，etc.
我学的是商科，有一些传媒背景，之前在奥美广告、澎湃新闻都有实习经历，正式工作后侧重在互联网和科技领域，目前在AI Agent做UG。我对用户增长的兴趣也覆盖到了播客领域，所以想要找志同道合的伙伴一起合作。
关于商业化，我的观念是内容为王，可以有为爱发电的精神，但是也要平衡商业目标，不然很难实现可持续发展。所有收入根据投入产出程度分配，我们可以商量具体的分成模式~
因为海外的播客商业模式更成熟，所以我们也可以一起做英文播客。我在美国待过一段时间，对美国文化有一些了解，我们可以考虑多渠道分发录制好的播客内容，让我们一起做有趣的内容吧☺️
固定嘉宾不用每期参加，我们可以轮流参与录制，话题倾向于AI、金融、科技、职场、文化、故事等，如果你有熟悉或者感兴趣的其他话题我们也可以商量~
如果邀请到飞行嘉宾，可以采用多人访谈的形式。我的朋友圈有几千人，涵盖金融、互联网、传媒等行业。播客数据好的话，我会鼓起勇气邀请朋友做飞行嘉宾。希望你交友广泛，能够一起邀请飞行嘉宾参与，让播客内容更多元。
我喜欢有观点也有态度的节目，比如今夜不设防，栋笃笑，锵锵三人行，The Tonight Show Starring Jimmy Fallon，Saturday Night Live，etc.
我学的是商科，有一些传媒背景，之前在奥美广告、澎湃新闻都有实习经历，正式工作后侧重在互联网和科技领域，目前在AI Agent做UG。我对用户增长的兴趣也覆盖到了播客领域，所以想要找志同道合的伙伴一起合作。
关于商业化，我的观念是内容为王，可以有为爱发电的精神，但是也要平衡商业目标，不然很难实现可持续发展。所有收入根据投入产出程度分配，我们可以商量具体的分成模式~
因为海外的播客商业模式更成熟，所以我们也可以一起做英文播客。我在美国待过一段时间，对美国文化有一些了解，我们可以考虑多渠道分发录制好的播客内容，让我们一起做有趣的内容吧☺️
5 63