我个人是不喜欢用 spec-kit，不是好的上下文工程： - 小项目没必要 - 大项目描述不清楚 - 一大坨文档反而占用上下文影响生成 - 文档不保持及时更新反而会误导 Agent 好的上下文管理是针对当前上下文引导 Agent 找到合适的刚刚好的上下文，而不是不管三七二十一塞给它十几个文档！

#spec-kit #上下文工程 #agent #上下文管理 #文档更新

相关新闻

九原客

1天前

如果对 DeepResearch 这类复杂的 Agent 感兴趣，我建议学一下LangGraph的免费课程 Deep Research with LangGraph。课程比较循序渐进，先做一个单Agent系统，然后进化为多 Agent。最主要是架构简单，外部依赖非常少，一个大模型一个搜索API就完了。

Y11

1天前

半年前，有位网友整理了一堆MCP工具资料，搭了个网站分享出去。初期他还手动维护，后来工具更新太快，一个人忙不过来，便写了个小程序——我们叫它“Agent”吧，让它自动去GitHub上搜集最新工具，分类整理后直接更新到网页上。之后他就没再管这个站了，忙着别的事，一晃半年过去。前几天他偶尔想起，随手在谷歌搜了一下，结果愣住了：自己早忘了的网站，赫然排在搜索结果第一。更意外的是，这个站从

宝玉

2天前

OpenAI DevDay: 超越提示词的艺术：AI 编程的未来是“上下文工程” 从自动补全到自主智能体，我们如何教会 AI 真正理解代码我们正处在一个非凡的技术变革奇点。软件开发的演进史，从穿孔卡片的笨拙到集成开发环境（IDE）的精妙，每一步都耗费了数十年光阴。然而，当我们踏入人工智能的时代，这场变革的节奏被极限压缩，数十年的进程仿佛在短短数年内上演完毕。我们与机器协作构建软件的方式，正在

𝙩𝙮≃𝙛{𝕩}^A𝕀²·ℙarad𝕚g𝕞

3天前

LLM客户端并无真正的“长期记忆”，而是通过“结构化存储 + 动态重构prompt”的方式模拟记忆。长会话上下文的核心任务在于取舍与压缩： •哪些历史内容保留？ •哪些内容通过摘要或检索再现？ •如何让prompt在token限制下仍保持语义连续？设计RAG，agent多轮对话，或者多agent与LLM交互，也要过类似LLM客户端上下文管理这一关！否则就是RAG猜，agent演，然后老板

Meathill

3天前

直到自己花钱订阅 GitHub copilot，我才想方设法让自己的 $100/y 花得值。准备下一阶段要按照自己 code review的能力上限用 Agent 帮我写代码，想来想去，Tutolang（视频创作小语言）可能是最合适的，希望年底前能做出来，试试看吧。