标签：#opensource

GitHub热门项目 | Open source Granola AI Alternative | Stars: 8,694 | 51 stars this week | 语言: Rust

GitHub热门项目 | Instant, Concurrent, Secure & Lightweight Sandbox for AI Agents. | Stars: 6,458 | 22 stars today | 语言: Rust

GitHub热门项目 | Generate any location from the real world in Minecraft with a high level of detail. | Stars: 16,200 | 44 stars today | 语言: Rust

GitHub热门项目 | A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust | Stars: 26,821 | 56 stars today | 语言: Rust

GitHub热门项目 | Shannon is an autonomous, white-box AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production. | Stars: 44,957 | 57 stars today | 语言: TypeScript

GitHub热门项目 | Promise based HTTP client for the browser and node.js | Stars: 109,082 | 8 stars today | 语言: JavaScript

GitHub热门项目 | JavaScript animation engine | Stars: 70,268 | 152 stars today | 语言: JavaScript

GitHub热门项目 | Official, AWS-supported MCP servers, skills, and plugins to help AI agents build on AWS | Stars: 958 | 13 stars today | 语言: Python

GitHub热门项目 | A community-supported supercharged document management system: scan, index and archive all your documents | Stars: 42,384 | 46 stars today | 语言: Python

GitHub热门项目 | from vibe coding to agentic engineering - practice makes claude perfect | Stars: 59,083 | 329 stars today | 语言: HTML

Every time I opened a fresh session with my coding agent, it started from zero. Which repos am I working across? Which client is this for? Where did we leave off yesterday? I'd re-explain the same context, the agent would occasionally load the wrong project, and nothing I decided last week survived into this one. A "re-explain myself" tax on every single session. I tried the obvious fix first — a better prompt, a longer system message. It didn't hold. Context that has to persist can't live inside the chat; the chat is the thing that resets. What actually worked: give the agent a place outside the chat to read and write — and make it the most boring, durable thing I could. Plain files in a git repo. The substrate: markdown + YAML the agent reads at session start open-bridge is a plain git repo of markdown and YAML. At the start of every session the agent reads it, so it begins already knowing my world. No database, no SaaS, no daemon, nothing to host — the substrate itself runs nothing . It's just files the agent reads. That "just files" choice is the whole point: Agents can read a file but can't hold an API key. What I write today, the agent still reads in six months — no migration, no second app, no vendor lock-in. It's auditable. Clone it and cat anything the agent reads. No black box. It's model- and tool-agnostic. Plain text is something every agent runtime can read. A tiny slice of what that looks like (from the repo's examples/agency setup — fictional "Acme Dev"): # ecosystem.yaml — the repos/clients the agent should know about projects : bigcorp : { display_name : " BigCorp E-Commerce" , repos : [ bigcorp-api , bigcorp-frontend ] } startupxyz : { display_name : " StartupXYZ MVP" , repos : [ startupxyz-app ] } # work/board.md — generated from the task dirs, read every session ## Doing | bigcorp-api-payment-retry | incident | P1 | Stripe webhook retries failing | | startupxyz-onboarding | feature | P2 | guided signup flow | So when I say "good morning, briefing

Spent the week breathing new life into DevNotion—59 commits and over 10,000 lines of code later,...

The easiest way to misunderstand LangGraph is to see it as “LangChain, but with more steps.” That misses the point. LangGraph becomes useful when an agent is no longer a single prompt or a simple chain. It becomes useful when the workflow has state, branches, tool calls, human approval, checkpointing, and recovery behavior that must be inspected before the agent is trusted inside a real AI host. I used the Doramagic LangGraph manual as the source-backed reading layer for this note: https://doramagic.ai/en/projects/langgraph/manual/ This is an independent project guide, not an official LangGraph document. I use it as a pre-adoption checklist: what should be understood before wiring a project into Claude, ChatGPT, Cursor, Codex, or another AI host. The point is not to create another prompt library. The useful artifact is a capability resource pack: a manual, source map, boundary notes, pitfall log, smoke check, lightweight eval criteria, feedback notes, and host-ready context that help a developer decide what to verify before adoption. 1. The real boundary is State, not the prompt For a one-shot model call, the prompt is often the main boundary. For LangGraph, the first boundary is the State schema: which fields move between nodes; which fields a node may update; how concurrent branches merge values; which values enter a checkpoint; which values should never be persisted. This is why reducers matter. A message list is usually not just overwritten. It needs an append or merge rule such as add_messages or the TypeScript equivalent. That small implementation detail decides whether parallel work preserves context or silently drops it. My preferred first run is not a “universal agent.” It is a tiny graph with one State schema, one node, one partial update, and one explicit reducer. If that is not clear, adding tools will only hide the problem. 2. compile() is the boundary between description and runtime Before compile() , a LangGraph graph is a description: nodes, edges, c

I kept running eslint and thinking my codebase was fine — then someone opened a PR and the first comment was "this function needs JSDoc." The problem: linters check your syntax . Nobody checks whether your exported API is actually documented. Those are two very different things. So I built jsdocscan — a zero-dependency CLI that walks your JS/TS files and flags every exported function or class that is missing JSDoc, or has undocumented parameters. What it catches Errors — exported function or class with no /** … */ block at all: ✗ src/api.js:12 fetchUser missing JSDoc ✗ src/utils.js:34 formatDate missing JSDoc Warnings — JSDoc exists but a parameter has no @param tag: ! src/render.js:7 renderCard undocumented params: opts Exit codes are 0 (all clean), 1 (issues found), 2 (usage error) — pipe-friendly. How to use it # scan a directory npx jsdocscan src/ # Python version pip install jsdocscan jsdocscan src/ # skip @param checks — just verify JSDoc exists npx jsdocscan --no-params src/ # machine-readable output npx jsdocscan --json src/ | jq '.[].findings' # summary line only npx jsdocscan --quiet src/ # custom extensions npx jsdocscan --ext .js,.ts src/ What it skips (intentionally) Non-exported functions and internal helpers — these are implementation details Destructured params ({ a, b }) — too many valid @param opts patterns TypeScript type annotations on params — name: string is stripped, @param name is still required Zero dependencies No parsers, no AST, no require("typescript") . It uses a line-by-line scanner that: Detects export function/const/class patterns via regexes Walks backwards to find a preceding /** */ block Compares @param names in the JSDoc against the actual parameter list npx jsdocscan works with zero install time. pip install jsdocscan brings in nothing extra. Links npm: npmjs.com/package/jsdocscan PyPI: pypi.org/project/jsdocscan GitHub (Node): jjdoor/jsdocscan GitHub (Python): jjdoor/jsdocscan-py Both versions pass the same 38-test suite. Same

I spent the last few months trying to understand why reconciliation errors keep appearing in high-throughput pipelines. Here is what I found. In the race to process millions of transactions daily, modern fintech ecosystems have achieved a genuine miracle of scale. But beneath the surface of that velocity lies a structural problem most engineering teams aren't measuring: causality violations in async event pipelines. Most teams assume that if a transaction shows "Success" in the database, the job is done. At high concurrency levels, that assumption breaks quietly. When "Eventual Consistency" Becomes "Eventual Loss" In distributed systems, Kafka partitions and database shards experience micro-millisecond timing gaps. When a network retry delays a validation webhook, the downstream ledger can commit a wallet update before the validation that should have preceded it completes. To the user, the app glitches. To the engineering team, it's a reconciliation ticket. To the CFO, it's untracked operational cost. The Reconciliation Tax I built a simulation modelling this exact failure mode across 5,000 concurrent transactions. With an 8% network retry probability, conservative for high-traffic payment rails, the causality violation rate was 8.3%. At one million daily transactions, that's over 80,000 unvalidated commits every day requiring manual review. The operational cost compounds across three dimensions: engineering hours spent patching database state, fraud model accuracy degrading on out-of-order training data, and audit trails that cannot demonstrate strict causal sequence to regulators. The Fix The solution is enforcing strict event ordering at the ingestion layer before state commits happen, not better monitoring after the fact. When safeguards including partition-aware routing, exponential backoff, and idempotency controls were added to the same simulation, the violation rate dropped to 0%. Full simulation code and methodology: github.com/yakuburoseline1-gif/cif-simul

I used Postman for years. It was the first thing I installed on every new laptop, the default answer...

去年我开始给 Hermes Agent 搞知识库。最初的想法很简单：装个向量数据库，查资料时能命中就行。结果跑了一圈发现—— 纯向量检索在 Agent 场景下不够用 。 有些记忆是你能精确描述的（"帮我查上次那篇讲 gbrain 孤页的文章"），有些记忆你只记得个大概（"有个关于知识图谱的……"），有些记忆你甚至不知道你该知道什么（"我有哪些笔记是没关联起来的？"）。一个检索策略覆盖不了这三种场景。 这就是 Knowledge-and-Memory-Management v0.0.2 解决的问题。 三层不是为了「多」，而是为了互补 项目是目前运行在 Hermes Agent 生态里的扩展层，底座是 hermes-memory-installer 提供的 gbrain（知识图谱）+ Hindsight（向量记忆）。KMM 在这上面加了四组模块：采集、笔记/RAG、云盘同步、知识增广。 其中最有工程价值的设计是 三层跨层召回 ： FTS5 全文搜索 → 精确命中，知道你要什么 Hindsight 向量语义 → 模糊配匹，关键词不够时靠语义 gbrain 知识图谱 → 关系探索，你不知道但相关的节点 lightweight_recall.py 把这三级串联成一条管线——先查本地 SQLite FTS5，命中直接返回；没命中走 Hindsight 的文本嵌入匹配；还不满意就用 gbrain 展开知识图谱的邻接节点。 代码在 $AGENT_HOME/scripts/lightweight_recall.py ，调用并不复杂： # 三层召回示例 from knowledge_collector.knowledge_management import KnowledgeManager km = KnowledgeManager () # 一次调用，三级自动回退 results = km . tiered_search ( query = " Agent 记忆系统设计 " , tiers = [ " fts5 " , " hindsight " , " gbrain " ], limit_per_tier = 5 ) for tier , hits in results . items (): print ( f " [ { tier } ] { len ( hits ) } 条结果 " ) for h in hits [: 2 ]: print ( f " → { h [ ' title ' ] } ( { h [ ' relevance ' ] : . 2 f } ) " ) FTS5 走 SQLite 内置，零依赖；Hindsight 端口 8890；gbrain 端口 8787。每层都是独立的可降级——向量服务挂了，全文搜索照样能跑。 真正干活的是这 40+ 工具 三层召回是检索层，采集层才是让知识库有东西可喂的入口。项目塞了 40+ 采集分析工具，按类型分： 网页采集（9 引擎） ：Scrapling 做反检测，Crawl4AI 做智能路由，爬公众号不走弯路 视频采集（12 工具） ：yt-dlp 拖流 → Whisper ASR 转写 → PaddleOCR 关键帧，抖音/YouTube 一把抓 文档分析（9 工具） ：SenseNova 三件套（PDF/PPT/Word）处理扫描件和复杂排版 书籍精炼（6 工具） ： book_to_skill 管线把 PDF/EPUB 拆成结构化 Skill + KMM 笔记 每周日凌晨还有个 knowledge_discovery.py 爬起来，扫 OneDrive 上的新笔记，自动录入 gbrain，顺便跑孤页链接修复——这些属于「你不需要知道它存在，但它让系统不腐烂」的基建。 几个工程取舍 不做纯向量优先 ：FTS5 第一级是因为延迟低（毫秒级），且精确关键词匹配在查代码、查配置时远好于语义 gbrain 孤页处理是刚需 ：知识图谱不加链接维护，三个月后 90% 的页面都成孤岛（亲测 10,666 页从 1,716 个孤页降到 33） 采集优先于检索 ：没有好的采集管线，检索再强也是对着空库跑——项目把采集工具堆到 40+ 不是炫技 适用场景 如果你的 Agent 需要从多个来源（网页、视频、文档、公众号）持续摄入知识，并且知识需要在精确搜索、模糊回忆和关系探索三个维度上都能命中——三层模式值得一试。不需要全部部署，只接 FTS5 + gbrain 两层也能跑，每层独立可降级。 GitHub: mage0535/Knowledge-and-Memory-Management ，MIT 协议。

GitHub热门项目 | The open-source CapCut alternative | Stars: 58,822 | 3,097 stars this week | 语言: TypeScript

I spent a week building Wingman , an open source MCP server that renders a persistent task panel inline in Claude conversations using MCP Apps (SEP-1865). The spec is solid. The SDK is solid. But I hit two bugs that cost me most of a weekend each, and neither is documented anywhere I could find. Writing them up here in case they save someone else the time. Bug 1: resourceUri has two valid-looking locations, and only one works MCP Apps needs a way to tell the host "render this resource as a UI for this tool call." That pointer lives in _meta.ui.resourceUri . The question is: meta on what? I started with a parameterized resource template, ui://wingman/panel/{plan_name} , registered per plan. That was my first mistake. Parameterized templates get listed under resources/templates/list , not resources/list , and hosts do not prefetch or render anything from the templates list. The fix was straightforward once I found it: register one static resource, ui://wingman/panel , and pass the actual plan data through structuredContent on the tool result instead of baking it into the URI. That fix surfaced the real bug. My show_plan tool was returning a plain Python dict: return { " plan " : plan_data , " _meta " : { " ui " : { " resourceUri " : " ui://wingman/panel " }} } This looks correct. It is not. FastMCP's result conversion takes a returned dict and serializes the whole thing into structuredContent , verbatim, including any _meta key the dict happens to carry. So the actual wire result looked like this: result . structuredContent [ " _meta " ][ " ui " ][ " resourceUri " ] # == "ui://wingman/panel", but wrong place result . meta # None — this is what the host actually reads MCP Apps hosts read resourceUri off the top-level _meta on the CallToolResult , not off whatever ended up inside structuredContent . With that pointer effectively missing, the host had nowhere to bind the iframe. The visible symptom was strange: actions in the UI would update on screen but nothing persist

Every time I added AI to a React app, I rewrote the same 200+ lines. Streaming loop. Manual message history. Tool call orchestration. Error handling. setIsLoading(false) only if I remembered. After the third project I stopped and asked: why is nobody solving this the way RTK Query solved REST APIs? So I built Strand ( https://github.com/strand-js/strand ). Before const [messages, setMessages] = useState([]) const [isLoading, setIsLoading] = useState(false) async function send(text) { setIsLoading(true) manually stream tokens manually detect tool calls manually loop until done setIsLoading(false) only if you remembered } After const { messages, send, isPending, isStreaming, cancel } = useConversation({ system: 'You are a helpful assistant.', }) Streaming, history, tool calls, cancellation, retry; all handled. The thing nobody else has: useToolCall Works from ANY component; no prop drilling function WeatherStatus() { const { status, input, output } = useToolCall('get_weather') if (status === 'running') return <div>Checking {input?.location}…</div> if (status === 'done') return <div>{output?.temp}°F</div> return null } Live tool state: pending → running → done. Its observable anywhere in your tree. Fixing the isLoading design flaw The Vercel AI SDK has 4+ open issues ( https://github.com/vercel/ai/issues ) about isLoading getting stuck. The reason is architectural because "request sent" and "tokens arriving" are different states. Strand tracks four: const { isPending, isStreaming, isDone, error } = useConversation() // isPending: waiting for first token // isStreaming: tokens arriving // isDone: just completed // error: something failed Works with Anthropic, OpenAI, and Google Gemini npm install @strand-js/core @strand-js/react zod npm install @strand-js/anthropic # or openai, or google Swap providers by changing one server import. Zero frontend changes. v0.1.8, MIT, open source. → https://github.com/strand-js/strand