agent 是智能体的意思，什么是智能体呢，为啥不叫AI了啊，也不叫大模型了，其实这并不是孤立的概念，AI中文就是人工智能，英文全称：Artificial Intelligence，其实就是计算机科学的一个分支，用来研究开发模拟，延伸人的理论方法技术和应用研究。大模型是ai具象化的技术产品，大模型还分了LLM语言大模型、VLM视觉大模型、MLLM多模态、技术上又出现了很多细节，比如混合专家模型-MOE。 MCP 是定的ai识别的上下文协议，用来，调用外部的服务器，返回固定内容信息的一个规则，大家都用这个规则，不就方便了ai调用外部工具获取信息了。方便打通不同企业数据库和ai的交互。 tools 就是工具的意思，这里和mcp紧密相连，tools泛指一类工具，遵循的上下文协议也未必是mcp。方便ai通过这个工具进行获取信息。 plugin是插件的意思，就是个扩展包，这不是ai独有的概念，浏览器有插件，任何应用都可能有插件，一个插件里面东西就多了，可以包含skill，agents，hooks，mcp severs等内容。 prompt是提示词的意思，大模型学的东西多了，大模型要在知识汪洋中预测你想要的下一个词，简直不要太难，那么就帮她缩小范围降低幻觉，那就是定人物，定任务范围，定目标，这样将结合以上的信息，进行数据处理，就大大降低了，大模型胡说八道的可能性。大模型本身就是个统计学问题，根本不具备任何智慧，和反思能力，并非动态进化的，而是提前通过人类社会无数的现有文档，向量化，然后通过多维向量的训练出来的，一个具备无数维度的数学矩阵，通过通过上下文的切割成token又称词元，一个词元就是一个数字，多个词元就组成了一个数学矩阵，将这个数学矩阵扔到transform架构的数学矩阵中。我也不知道是不是百亿参数是不是也决定了词元的数量呢，会影响回应呢？ workflow就是工作流，针对一项工作设计的工作流程，使其完成特定的任务，取代繁重的工作。 hook钩子的意思，什么是钩子啊就是，当执行到特定情况或者涉及特殊判断的时候就会触发的程序，相当于一个钩子，勾住了你的工作流，在特定情况下触发，进而保证进程的稳定和顺利。 skill技能的意思，技能可以是一个md说明的工作文档，也可以是md说明文档加一些小程序、或者一些模板的综合体，目标就是让大模型能按你的md说明文档进行工作。 harness就是一个工作台，工作台上啥也有，自由搭配，想用啥就用啥，比如有plugin、tools、prompt、workflow、hook、skill、和设定好的agent。 AI / 人工智能 └── 大模型 / LLM / VLM / MLLM └── Agentic System / 智能体系统 ├── Prompt：给模型的指令 ├── Context：当前任务上下文 ├── Memory：可长期保存或检索的历史信息 ├── Tools：模型可调用的外部能力 │ └── MCP：连接 tools / resources / prompts 的标准协议之一 ├── Workflow：预设流程 ├── Hook：生命周期触发器 ├── Skill：可复用能力包 ├── Plugin：可安装扩展包 └── Harness：运行框架 / 执行外壳 agent 是配置了 instructions、tools，以及可选运行行为的 LLM MCP Server 可以向 AI 应用暴露 resources、prompts 和 tools。这样不同 AI 应用和不同外部系统之间就不用每次都重新写一套私有接口。 Tool：一个具体能力 MCP Tool：通过 MCP 协议暴露出来的 tool MCP Server：把一组 tools / resources / prompts 提供给 AI 应用 Agent：根据任务需要决定是否调用这些工具 plugin 可能包含 tools、skills、agents、hooks、MCP servers 等内容。简单说，plugin 是“打包和分发能力”的方式。 prompt 帮模型缩小范围，降低幻觉。这个是对的。OpenAI 文档也把 prompt engineering 描述为编写有效指令，让模型更稳定地产生符合要求的内容。 大模型本质上是通过大量数据训练出来的神经网络，它没有人类意义上的主观意识，也不会在普通对话中自动修改自己的模型参数。它的回答来自当前输入、上下文、训练得到的参数，以及推理时的生成过程。我们看到的“推理”“反思”“自我检查”，更多是模型在特定提示、上下文或工具流程下表现出来的能力，而不是人类式的自我意识。 Token：文本被切分后的处理单位。 Token ID：token 被映射成的数字编号。 Embedding：token ID 进入模型后对应的向量表示。 Parameter：模型训练出来的权重和偏置。 Context window：一次输入/输出能处理的 token 上限。 Training tokens：训练时看过的数据 token 数量。 Vocabulary size：分词器支持的 token 种类数量。 文本会先被 tokenizer 切成 token，再映射成 token ID。模型会把 token ID 转成向量表示，也就是 embedding，然后送入 Transformer 网络中计算。Transformer 通过注意力机制和多层神经网络，结合上下文预测后续 token。参数量指的是模型内部训练出来的权重数量，和输入 token 数不是同一个概念。 Workflow 是预先设计好的流程。它强调“步骤固定、路径清楚、可控性强”。比如先读订单，再判断退款规则，再调用退款接口，再发送通知。workflow 里可以用大模型，也可以不用大模型。它和 agent 的区别是：workflow 的路径主要由人或程序提前写好；agent 的路径更多由模型根据目标和中间结果动态决定。 Anthropic 对这个区别说得很清楚：workflows 是 LLM 和工具通过预定义代码路径编排；agents 则是 LLM 动态决定自己的流程和工具使用。 这个方向对。Anthropic 的 Agent Skills 文档也把 skill 描述为模块化能力包，包含 instructions、metadata 和可选资源，比如 scripts、templates，Claude 会在相关任务中自动使用。 另一个官方指南也说 Skills 可以是由 instructions、scripts、resources 组成的文件夹 Context：这次对话/这次任务临时放进来的信息。 Memory：跨会话保存、以后还能拿出来用的信息。 Context 是模型当前这次任务能看到的信息，比如用户问题、系统指令、聊天历史、检索到的文档、工具返回结果等。Memory 是被长期保存、之后还能被取出来的信息，比如用户偏好、项目背景、历史决策、常用规则等。Memory 不是模型参数本身发生了变化，而是系统把相关历史信息保存下来，在需要时重新塞回 context。 5 个帖子 - 4 位参与者 阅读完整话题
fast-context mcp 慎用吧，直接给我注入攻击脚本执行，也是666了。代码本身正常没有外部调用，但是只要调用fast-context，ai就会读取到里面有攻击脚本 卸载了就正常了 claude mcp remove fast-context -s user 5 个帖子 - 5 位参与者 阅读完整话题
/context 查看当前token占用情况, 如果存在某个地方占比太多可尝试优化 若 skills 加载过多, 可以尝试用过cc-switch 进行统一控制, 或者在头部加上 disable-model-invocation:true 这样 skill 的描述不会进入上下文，只有用户手动调用 时才会加载完整内容; user-invocable: false 可以用于skill在菜单的可见性 善用/init 总结项目, 如果claude.md太多, 可以按照设置 rules/ 文件夹定义paths 参数, 控制特定路径下文件规则, 并且只会在匹配到paths时才加载进入上下文中 善用 sub-agent ; 保护主上下文的token占用; 对于一些比较基础的工作, 完全可以定义个对应的sub-agent, 然后指定便宜的 model :haiku , mcp, skill 等属性 , 加载指定工具, 去节省token开支; 而且如果之前上下文已经启用了这个sub-agent, 后续还有相同的工作, 可以继续resume或者 SendMessage 复用之前的sub-agent 对于 mcp 这个加载的占用token情况最严重 , 除非必要的mcp, 不然最好还是禁止加载,定义参数toolsearch: “ENABLE_TOOL_SEARCH”: “true” 交于claude code 控制加载; 以及需要的时候在定义在当前项目的json文件中; 然后如果存在对应的cli 工具, 建议直接诶使用cli 工具提供的skill, 将其token占用进一步收敛, 毕竟skill也是按需加载, 需要的时候才会把上下文加载进去; 建议多手动**/compact** , 在70/80 % 时, 可以手动总结, 防止模型失智; 并且可以自定义相关hooks 在新模型中自动加载之前上下文总结内容, 预防新开窗口失忆 (这个后续hooks可以新开一篇详细说说) 市面上也有相关的工具, 例如 rtk 精简命令执行; caveman 简化输出风格; 或者直接/config 自定义一个 Output style; 1 个帖子 - 1 位参与者 阅读完整话题
各位佬友好，我是Jia，一名有着9年AI经验的00后，同时也是开源项目 Spice 的创始人，Spice 是我做的一款开源项目，一句话总结是 the decision layer above agent，即做 Agent 之上的决策层，最近在探索如何收取到更多不同维度的 context，通过不同入口的 context 来更好的展示 Spice 的价值。想拿出来讨论下，也欢迎大家一起来讨论与指正。 目前的 Agent 已经在数字世界大放异彩，无论在能力平权方面，还是生产力提升方面，这些发展验证了给 Agent 足够多的 context 他就有无限可能，未来 AI 公司的竞争也逐渐从技术能力转化到谁能拥有更多用户的 context，谁能维护更好的 state，以及做更好的自进化就会有更深的壁垒。 在这种发展下越来越多的人和公司意识到这一点，然后尝试做更多的 context 入口，收取更多的 context，比如越来越多的智能穿戴设备（眼镜，手表，项链，手环，耳机等等），甚至 OpenAI, Apple这样的大厂也开始做更多这样的尝试，从数字世界的 computer use 到物理世界的各种终端设备，通过不同维度不同类型的 context 从而让 AI 更好的深入我们的生活。 我们做 Spice 的时候为了找一个载体也想过这个问题，单拿硬件设备来说，目前所有终端设备都有不可替代性和弊端（眼镜最符合人类视角但功耗舒适度很难解决，手表可以采集部分健康数据但视觉数据不理想），那未来是否有一个终端可以采集一个人所有的context（脑机接口？隐形眼镜？ and what？），我们也在做智能穿戴方面的尝试，比如pin… 从数字世界来说，computer use这个 part 做的人也越来越多了，openai 的 chronicle， air jelly等等，在 computer use 这方面发展的方向有很多，比如是预测用户下一个的 keystroke，或者预测用户一个小时后可能会做的事情，你可以通过 screen shot 的方式截屏收集 context，也可以通过绑定某个按键去识别数字世界的人类意图，这里能做的尝试也有很多，比如我们在尝试绑定 enter 键及 command tab等。 想问问佬友们为了实现更好的全域 context，有哪些更好的硬件及软件配合的方案及尝试，有更好的更全面的收集 context 的方式，实现 AGI 的方式一定是靠多个 Agent 网络，Spice 在尝试做这个多个 Agent 的控制层，未来越来越多的 Agent 会深入大家的生活，这将是很重要的一步，欢迎大家来一起讨论呀！ 3 个帖子 - 2 位参与者 阅读完整话题
最近在研究 MCP （ Model Context Protocol ）在专业领域的落地应用，搭了一个开源的 AI 工作台 AI Workdeck 。 核心思路是：把各种文档处理能力封装成 MCP Server ，然后用 Agent 来编排调用。 举个例子，在法律文档审查场景里： 合同解析 MCP Server — 负责提取条款、识别风险点 比对 MCP Server — 负责文档版本对比 检索 MCP Server — 负责从知识库中检索相关法规 然后通过 Agent 编排，用户只需要上传文档，系统自动调用相关工具完成分析。 技术栈： 后端用 FastAPI MCP Server 用 Python SDK Agent 层支持多种编排模式 前端用 Next.js 相比直接用 ChatGPT 处理文档，这种架构的好处是每个 MCP Server 可以独立开发、测试和部署，而且可以复用社区已有的 Server 。 项目完全开源，欢迎感兴趣的同学一起交流。 GitHub: https://github.com/zeweihan/aiworkdeck
AI 编程工具越来越强，也越来越贵。 Augment 的定价已经让很多开发者开始重新计算成本。 SuperMemory 的方向是对的，但价格却依然不低。 所以我们做了 Not ACE 。 Not ACE 是一个更低成本的 AI 编程记忆层，面向 Coding Agent 工作流： 兼容 SuperMemory API 面向 ACE / Augment 风格工作流 内置 Memory Graph 支持 MCP / SDK 限时免费开放 我们希望 AI memory 不再是一笔高价订阅，而是每个开发者都能接入的基础能力。 官网： https://not-ace.ame.rip
AI 编程工具越来越强，也越来越贵。 Augment 的定价已经让很多开发者开始重新计算成本。 SuperMemory 的方向是对的，但价格却依然不低。 所以我们做了 Not ACE 。 Not ACE 是一个更低成本的 AI 编程记忆层，面向 Coding Agent 工作流： 兼容 SuperMemory API 面向 ACE / Augment 风格工作流 内置 Memory Graph 支持 MCP / SDK 限时免费开放 我们希望 AI memory 不再是一笔高价订阅，而是每个开发者都能接入的基础能力。 官网： https://not-ace.ame.rip
AI 编程工具越来越强，也越来越贵。 Augment 的定价已经让很多开发者开始重新计算成本。 SuperMemory 的方向是对的，但价格却依然不低。 所以我们做了 Not ACE 。 Not ACE 是一个更低成本的 AI 编程记忆层，面向 Coding Agent 工作流： 兼容 SuperMemory API 面向 ACE / Augment 风格工作流 内置 Memory Graph 支持 MCP / SDK 限时免费开放 我们希望 AI memory 不再是一笔高价订阅，而是每个开发者都能接入的基础能力。 官网： https://not-ace.ame.rip
AI 编程工具越来越强，也越来越贵。 Augment 的定价已经让很多开发者开始重新计算成本。 SuperMemory 的方向是对的，但价格却依然不低。 所以我们做了 Not ACE 。 Not ACE 是一个更低成本的 AI 编程记忆层，面向 Coding Agent 工作流： 兼容 SuperMemory API 面向 ACE / Augment 风格工作流 内置 Memory Graph 支持 MCP / SDK 限时免费开放 我们希望 AI memory 不再是一笔高价订阅，而是每个开发者都能接入的基础能力。 官网： https://not-ace.ame.rip
AI 编程工具越来越强，也越来越贵。 Augment 的定价已经让很多开发者开始重新计算成本。 SuperMemory 的方向是对的，但价格却依然不低。 所以我们做了 Not ACE 。 Not ACE 是一个更低成本的 AI 编程记忆层，面向 Coding Agent 工作流： 兼容 SuperMemory API 面向 ACE / Augment 风格工作流 内置 Memory Graph 支持 MCP / SDK 限时免费开放 我们希望 AI memory 不再是一笔高价订阅，而是每个开发者都能接入的基础能力。 官网： https://not-ace.ame.rip
近期在玩Pi，在pi.dev上发现有pi的package，排名第一的是一个叫context-mode的包，生成能够减少98%的token用量，github repo在此 mksglu/context-mode: Context window optimization for AI coding agents. Sandboxes tool output, 98% reduction. 15 platforms 原理（repo原文翻译，不是AI生成 我用的有道，哈哈哈哈）： 1. 保存上下文 - 沙盒工具将原始数据保存在上下文窗口之外。 2. 会话连续性--每个文件编辑、git 操作、任务、错误和用户决策都会在 SQLite 中进行跟踪。当对话压缩时，上下文模式不会将这些数据转回上下文，而是将事件索引到 FTS5 中，并通过 BM25 搜索只检索相关内容。该模式会从您离开的地方重新开始。如果您不继续，之前的会话数据会立即被删除--新的会话意味着一片空白。 3.用代码思考 - LLM 应该对分析进行编程，而不是计算。代理不需要在上下文中读取 50 个文件来计算函数，而是编写一个脚本来进行计算，并只在 console.log() 中显示结果。一个脚本取代了十次工具调用，节省了 100 倍的上下文。这是所有 16 个平台都必须采用的范式：不要再把 LLM 视为数据处理器，而要把它视为代码生成器。 4.没有散文式的强制执行--上下文模式使原始数据不脱离上下文，但从不规定模型如何写出最终答案。简洁性、完整性、格式--由你的模型决定（或由你通过自己的 CLAUDE.md / AGENTS.md 决定）。咄咄逼人的简洁性提示已被证明会降低编码/推理基准（kimi-k2.5 上的 Mooonshot AI）--路由块始终关注的是数据的去向，而不是模型如何说话。 看起来很make sense，刚开始在Pi里面使用。不知道会不会出现为了节省上下文而导致模型智障的问题。 4 个帖子 - 4 位参与者 阅读完整话题
求助佬友，Windows的computer use操作软件经常触发node_repl exec context not found，应该怎么解决呢 4 个帖子 - 4 位参与者 阅读完整话题
想问一下佬们，用的是ccs，调用中转站的api，是gpt5.5用codex 为什么context没有用1M，需要设置config嘛，如果要的话，应该怎么设置？（我看ccs里面没有1M上下文选项了） 9 个帖子 - 4 位参与者 阅读完整话题
IDE: vs2022, vscode mcp: serena, context7 skills: superpowers 初始prompt: 将 "RTXPT" (D:/RTXPT-fork) 的实时路径追踪渲染管线移植至 DiligentEngine，作为一个Sample：RTXPT，位于 "DiligentSamples/Samples/RTXPT"。 项目 RTXPT 位于 "D:/RTXPT-fork"，可使用Serena mcp tools访问。 将移植任务分为多个大阶段，包括初期调查、移植资源创建和初始化、移植资源更新（比如BLAS/TLAS，灯光参数等）、移植绘制调用（包括TraceRay调用和Compute调用）、移植着色器、移植后处理总共6个大阶段。 尽量完整复刻 RTXPT 当前高级样例的全部能力，但是你可以先从最小可运行 Sample做起，每一步移植任务完成后都必须确保可Sample运行，以便我验收单次移植任务。 移植过程中未完成的地方应当在代码中留//TODO 我需要同时支持Diligent的D3D12和VULKAN后端，因为RTXPT使用的NVRHI也是同时支持D3D12和VULKAN后端的。 目前进度： 基本框架√ 场景资源加载√ 渲染管线 着色器 后处理 4 个帖子 - 2 位参与者 阅读完整话题
codegraph 和 fast_context 是同样的功能吗？小白求教 2 个帖子 - 2 位参与者 阅读完整话题
codex app 的 context 使用率是不是被砍了，今天发现原本那个圆形的统计 icon 没了。也没找到其他地方查看。奥特曼开始不当人了？ 现在看不到很难做主动压缩的决策了。一旦 context 接近满了压缩一次都很耗 token，并且一旦压缩过之后，会话后续的 token 都会非常烧 token。 4 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - Dyalwayshappy/Spice: A decision brain for agentic systems: perceive... A decision brain for agentic systems: perceive context, compare options, and control execution. Hi各位佬友，我是Jia，一名有9年AI经验的00后，同时也是 Spice 的创始人，前面两条关于 Spice 的 post 分别讲了 Spice 的起源，架构及和普通 Agent 在方法论上的区别，很多佬友给我点了 star 和 fork，不同的朋友用在了 research，产品经理 agent，做量化等等，感谢大家给我们的反馈，今天想从另一个角度聊聊 Spice 特别的地方。 1. 从 Prompt 到 Context，再到 State 从24年开始火的 prompt engineering，到25年的 context engineering，Agent 的工程重心一直在往前移，最早关心的是“如何让模型按预期回答”于是有了 prompt engineering，后来想解决“怎么把正确的信息放入上下文”有了 context engineering，再往后我认为会变成“如果长期有效地维护用户的状态”，让 Agent 长期且深入的进入用户的生活，在Spice里我叫做 State Engineering 简单概括： Prompt Engineering 解决的是：模型这次该怎么说 Context Engineering 解决的是：模型这次能看到什么 State Engineering 解决的是：系统现在相信什么，模型基于什么来做下一次决策 这也是我现在理解 Spice 的核心之一：不是让 context 更长，而是让 state 更可靠 2. Prompt Engineering：控制模型如何回答 早期大家做 LLM 应用的时候，模型会跑题，格式不稳定，不按要求输出，这个问题很简单：“模型太自由了”，同一个问题，不同的 prompt 会得到完全不同的回答，所以早期的 Prompt Engineering 本质是在一次模型调用里，通过 system prompt、role prompt、step-by-step、output schema 等方式约束 LLM “这次该怎么回答”。 Prompt Engineering 让 LLM 从一个 chatbot 变成了可以被产品调用的能力。只要prompt 足够清晰，模型就能在一个稳定的边界内完成任务，现在很火的 skills，本质上也继承了 prompt engineering 的思路。以及那时候很多垂直领域做的套壳 Agent，所以 prompt engineering 解决的是 instruction 的问题。 但 prompt engineering 的边界也很明显，他的主要作用是在单次调用里，他能约束模型“这次该怎么回答”，但当一个 Agent 需要长期运行，问题就不只是 prompt 写得好不好了，而是模型每次回答时，到底能不能看到正确、相关、及时的信息。于是问题自然转向了 context 3. Context Engineering：让模型看到正确的信息 当 prompt engineering 把LLM的回答变得相对可控以后，大家很快发现另一个问题：模型会回答问题了，但是时常因为上下文缺失，看不到“正确信息”而导致回答失真。 比如它不知道当前项目的代码结构，不知道用户之前说过什么，不知道外部工具刚刚返回了什么。这时，只靠把 prompt 写得更好是不够的，因为问题不在 instruction，而在 context 于是围绕着 Context 问题有了很多工程方法： RAG， memory，session history，context packing等等。他们都在解决如何把这次任务有用的信息，尽可能准确的放到 LLM 的上下文里。 模型不再只是依赖参数里的“知识”，而是可以结合用户历史、文档、代码、工具结果和外部环境来完成任务。很多 Agent 能不能工作，关键不在模型本身，而在 context 是否组织得足够好。（Manus是那时候 context engineering 做得好的代表） 但 context engineering 也有他的边界， 他本质上还是在给 LLM 组装一次推理时的 working set 。 他像是一个“临时缓存视图”，当模型遇到相关 Task 时，系统从 memory、工具结果、历史记录里找出一批可能相关的内容，然后放进 context，让 LLM 在这次调用里参考这些材料。25年一整年所有 LLM 都在疯狂的拉大自己的 context window，以及后续 Agent 关于处理 long context 的 compaction 等解决方案。 所以 context 可以告诉模型“你这次可以参考什么”，但当我们使用 Agent 的程度越来越深，数量越来越多，你是不是也烦恼不同 Agent 之间的 context 不互通（当然现在有很多A2A）， context 散落在不同的角落，这时系统需要维护的不只是每个 Agent 里更大的 Context。 我们把下一层称为 State Engineering 4. State Engineering：从上下文转变为状态建模 如果说 context engineering 解决的是“模型这次能看到什么”，那 state engineering 想解决的是：“系统现在到底相信什么” 及系统在当前的状态。这里的 state 不是再是简单的 context 问答， 也不是把所有历史记录都塞入 memory， 他是系统对用户所处“世界”的建模，对当前用户、环境、任务和约束的一份可更新投影 ，一个新信息进来以后，系统需要判断它是否真的改变了当前状态，而不是简单地把它存下来，等下次再召回。 比如某个 Agent 今天执行一个任务失败了。context 里可以记录这次失败，但系统不能立刻得出“这个 Agent 不适合做这类任务”。它需要看失败原因是工具权限、信息缺失、执行错误，还是任务本身不可行。不同归因会导致完全不同的下一次决策。 所以 State Engineering 关心的是一个更完整的链路： signal -> observation -> evidence -> reducer -> state -> decision -> outcome feedback signal 是外部发生的原始输入无论物理世界还是数字世界，比如用户一句话、一次工具调用结果、一个传感器事件、一次任务失败。 observation 是系统从 signal 中识别出来的结构化变化。 evidence 是支撑这个 observation 的来源和证据。 reducer 决定这个 observation 是否应该更新 state。 state 再影响下一次 decision。 decision 的结果和用户反馈，又会反过来更新 state。 这听起来很像一个结构化的 memory， 但其实 memory 和 state 不同，memory 更像是为了召回和压缩服务的缓存，它可以帮助系统在需要时找到过去的信息。但 memory 里的东西可能过期、冲突、错误，也可能只是历史记录。State 则应该是经过验证、归因和更新后的当前投影。 所以 state engineering 不是单纯地做更大的 memory，也不是把 context window 拉得更长，而是让系统知道：当前的完整状态是什么样，哪些信息被接受为当前状态的一部分，哪些信息只是历史材料，哪些信息应该失效，哪些信息会影响下一步决策。 5. Spice - Decision Layer 放在这个演进里看，Spice 不是想替代 prompt engineering 或者 context engineering，Spice 关心的是如何把这些进入系统的 signal 转化成用户的长期 state， LLM 每次基于当前 state 进行辅助决策及推演，记录决策与执行结果然后不断的更新 state，所以我更愿意把 Spice 称为一个 decision layer。 有些佬友和朋友问我，Spice 和 Harness想解决的事情是不是差不多，Harness 更关注的是“怎么执行”：比如如何隔离运行环境，如何调用工具，如何管理流程，如何记录日志，如何保证执行安全。它包在 agent 或 executor 外面，让执行过程更可控。对于 Spice 来说，更关注的是“为什么执行”：在真正调用 executor 之前，系统当前处在什么状态？有哪些可选 decision？每个 decision 的依据是什么？选择某个candidate会发生什么？ 是否符合用户偏好和约束？执行后的结果又如何改变下一次 decision？也就是说，harness 管的是 execution control，Spice 想管的是 decision control。我们的目的都是让 Agent 可以更好的完成任务，能长期的存在于我们的生活中，只是关注的是不同的 layer。 用一个简单的链路表示： context / signal -> observation -> state -> candidate decisions -> compare / approve -> execution handoff -> outcome feedback 这里 executor 可以是一个 coding agent、一个 research agent、一个 browser automation、具身机器人等。Spice 不一定要替代它们，而是希望在它们之前，提供一个更清楚的 decision interface 以及维护一个完整的 state，充当这些 Agent 的大脑。 6. 总结 Agent 系统真正难的不是再加一个 skill，也不是再包一层 executor，而是如何维护一个可追溯、可更新、可被验证的 state，并让它稳定地影响下一次 decision。让每次结果能更好的归因，能清晰的了解这个 “黑盒” 里是如何决策的，让 Agent 真正具备长期存在和持续进化的能力。 这些问题如果不解决，Agent 就很难真正长期运行。它可能短期看起来很智能，但跑久以后 state 会漂移，memory 会堆积，错误归因会累积，最后系统越来越难解释，也越来越难修正。 这也是我想做 Spice 的重要原因之一，它不是为了让 Agent 显得更“聪明”， 而是为了让 Agent 的长期决策过程更可追溯、更可修正、更可进化。 更多有关 Spice 的内容各位佬友可以去我之前的帖子，也可以上我的 Github 研究一下，非常希望大家 star 以及 fork 下来试用一下，多多给我们反馈也欢迎一起共创，大家有任何问题可以评论区找我啊！ 1 个帖子 - 1 位参与者 阅读完整话题
Codex Desktop / VS Code 扩展里的 context window 使用占比圆盘/指示器消失了 请问有遇到过类似情况的吗？这个怎么解决？ 3 个帖子 - 3 位参与者 阅读完整话题
会有请求像这个样子，context canceled，然后在 cli 或者编辑器就直接中断了，后台也看不到报错，就只有context canceled 2 个帖子 - 2 位参与者 阅读完整话题
各位 V 友，AI 编程工具现在越做越重，文件目录稍微大一点，上下文就被各种 Grep 和日志给污染了，Token 费用直线上升。 看了下 Antigravity 2.0 里的 define_subagent 和 invoke_subagent 流程，通过给子代理限制 Tool 范围与分配隔离分支，成功实现了多线程并行的 codebase 检索，感觉是目前工程上比较优雅的降噪方案。 随笔写了一篇技术分享，求大佬们提提意见： https://aidevhub.net/blog/google-antigravity-subagent-orchestration