今日已更新 88 条资讯 | 累计 42797 条内容
关于我们

标签：#opensource

找到 2510 篇相关文章

AI 资讯

Open Source Project of the Day (#104): AgentScope 2.0 — Alibaba's Production-Ready Agent Framework Built Around Model Reasoning

Introduction "Build and run agents you can see, understand, and trust." This is article #104 in the Open Source Project of the Day series. Today's project is AgentScope 2.0 — Alibaba DAMO Academy's open-source production-ready agent framework. The agent framework space is crowded. LangChain centers on chain-based orchestration. AutoGen centers on multi-agent conversation. CrewAI centers on role-based collaboration. AgentScope's differentiation is in its design philosophy: when LLM reasoning is strong enough, the framework should step back rather than constraining the model's decision space with rigid pipelines. AgentScope 2.0 adds the production infrastructure that philosophy requires: event system, permission controls, multi-tenant isolation, sandbox execution, middleware hooks. The goal is not a demo that runs — it's a system that ships. What You'll Learn AgentScope 2.0's design philosophy: why "model-led" over "fixed pipeline" The five core systems: Event / Permission / Multi-tenancy / Workspace / Middleware Agent Team pattern: how the Leader-Worker architecture handles complex tasks Permission system fine-grained control: tool call approval and boundary configuration Positioning differences vs. LangChain and AutoGen The full ecosystem: AgentScope Runtime, ReMe, OpenJudge, Trinity-RFT Prerequisites Familiarity with LLM agent concepts (tool use, reasoning loop) Basic Python async programming Experience with LangChain or AutoGen helps with positioning comparison Project Background What Is AgentScope? AgentScope 2.0 is a production-ready agent framework — "an agent development platform with essential abstractions, designed to work with rising model capability, with built-in production support." The core problem it addresses: traditional agent frameworks constrain LLMs with rigid pipelines and opinionated prompt templates. As LLM reasoning capability has improved rapidly, that constraint has become a bottleneck. AgentScope shifts to "letting the model's native reason

2026-06-24 原文 →
AI 资讯

I was tired of heavyweight dev tools — so I built my own

I'll be honest — I didn't set out to build a developer tool. I'm an engineer by trade. I build structural and forensic engineering software. C++, WinUI 3, heavy desktop apps. But a big chunk of my prototyping and internal tooling happens in Python — and every time I sat down to spin up a quick Python desktop app, I hit the same wall. Every launcher, every hot-reload tool, every dev cockpit I found wanted something from me. Install this. License that. Set up a virtual environment. Add five dependencies just to watch a file change. I just wanted to run my app, see it update when I changed something, and get back to work. So I built ILX Launcher. The rule I gave myself was simple: pure Python stdlib and tkinter. Nothing else. If it couldn't be done with what Python already ships with, I didn't need it. What came out of that constraint surprised me. No pip install. No virtual environment required. No licensing headaches. You clone it, you run it, it works. That's it. It's a developer cockpit for Python desktop apps — run, hot-reload, test, profile, and ship, all from one place. The kind of tool I wished existed six months ago. It's early. It's rough around the edges. But it works, and it's already saving me time every single day. If you've ever felt like your dev tooling was getting in the way of actually building — I'd love for you to try it and tell me what you think. 👉 github.com/ilxstudio/ILX-Launcher And if it saves you even five minutes — drop a ⭐ on the repo. It genuinely helps others find it.

2026-06-24 原文 →
AI 资讯

I Wanted AI Code Review I Could Actually Own. So I Built Codra.

I wanted AI code review I could actually own. Not access through a subscription or a black-box service with its own limits. The deployment, credentials, providers, and usage under my control. I kept hitting usage limits mid-week during deep building sessions. The models were capable. The workflow was useful. But access still depended on somebody else's weekly allowance, and centralized platforms can change whenever the company behind them decides to. Pricing, quotas, models, plan boundaries. A workflow that fits this month may sit behind another subscription next month. I could not find a reliable open-source option that gave me the ownership model I wanted. So I built one. That became Codra : A self-hosted AI review engine built around bring-your-own models, your own data boundary, and no Codra-imposed usage ceiling. What Codra Is Codra is an open-source, self-hosted AI code review engine for GitHub pull requests. It listens to pull request events, reviews changed files, posts inline findings, and provides a dashboard for jobs, repositories, model routing, history, usage, and failures. It runs on Cloudflare Workers and uses: Cloudflare Queues for review jobs PostgreSQL through Hyperdrive for storage KV for sessions and cache A React dashboard for operations The GitHub App, model credentials, database, and review history are yours. Provider keys are encrypted with AES-GCM using your deployment secret. Bring Your Own Model, Bring Your Own Limits Changing providers does not require replacing your review history, configuration, or workflow. You configure the provider and model. Supported: OpenAI-compatible APIs OpenRouter Anthropic Google / Gemini Cloudflare Workers AI Why Self-Hosted Matters Here A large frontend repo and a tiny backend repo should not need the same review strategy. Each repository gets its own review settings. You tune triggers, skip generated files, ignore drafts, use mention-triggered reviews, configure labels, set file limits, and define custom ru

2026-06-24 原文 →
AI 资讯

The Tool Found Corridor Nodes — But the Bigger Finding Was Where It Found None

A few weeks ago I published corridor-lab — a Docker lab that proved a triage mismatch: a service that stores nothing sensitive can become high-priority because of where it sits in the path to a sensitive downstream system. The lab proved the premise. The next question was whether a tool could identify those nodes automatically — without manual path declaration, without value labels, from graph position alone. So I built corridor-id. You point it at a Docker Compose file. It discovers the topology, computes depth from exposed surfaces, and identifies which nodes expand forward reach into deeper parts of the environment. No asset-value labels. No sensitivity ratings. No human classification. Reach and graph position only. Then I pointed it at four architecturally different Docker environments. Two had corridor nodes. Two had none. Both answers were useful. But the zero-corridor results taught me more than the positive ones. What corridor-id does The tool reads a Docker Compose file and builds a reachability graph from service definitions, network memberships, and port mappings. It then orients that graph from exposed surfaces using BFS and identifies nodes that provide forward reach — access to strictly deeper nodes that the exposed surface cannot reach directly. The output is a ranked list with two metrics: exposure distance (how close to the surface) and forward reach gain (how many deeper nodes become reachable through this node). One command: python corridor-id.py docker-compose.yml No manual path declaration. No value labels. No configuration. From graph position alone. The four tests corridor-lab — segmented, depth 3 My own lab, five services across five segmented networks. The tool independently identified status-api as a corridor node — the same finding the lab was built to prove. Corridor nodes found: 3 → status-api Exposure distance: 1 Forward reach gain: 1 → log-monitor Exposure distance: 1 Forward reach gain: 1 → internal-admin-api Exposure distance: 2 For

2026-06-23 原文 →
AI 资讯

Your AI coding agent forgets everything every session. I fixed it with markdown and YAML.

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

2026-06-23 原文 →
AI 资讯

Do not treat LangGraph as a longer chain: define state, interrupts, and recovery first

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

2026-06-23 原文 →
AI 资讯

My code reviewer kept asking for JSDoc — so I built a zero-dep CLI that catches it first

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

2026-06-23 原文 →
← 上一页 下一页 →