AI Agent GitHub Digest — 2026-10-24

🌏 中文版

Today's Highlight

Today's throughline is making sure an agent actually did the right thing. ifixai turns auditing into a standalone, adversarial open-source test; crewAI 1.15.29 folds an eval/guardrail runner directly into its core commands; and Pydantic AI v2.60.0's compatibility notes tighten the boundary around untrusted input and around multiple MCP servers sharing one host. IntentKit and Kronos push the territory outward from two other angles — the first turns a team of agents into a self-hosted cloud service, the second builds a foundation model specifically for financial candlestick data.

Trending Repos

ifixai-ai/ifixai ⭐ 34k

GitHub　·　Python　·　Apache-2.0

• What it is: A standalone open-source CLI that audits an already-deployed AI agent against the role and permissions it's supposed to have. It drops the agent into a simulated version of your business, sends the kind of requests a real day brings — including ones that push deliberately past its role — and has a model from a different provider judge every reply.
• Why it's worth a look: The audit logic is deliberately decoupled from the agent's own test suite, and the rules require the judge model to come from a different provider than the agent being tested, so you're never grading your own homework. It ships with 10 default inspections (61 with --full-run), scores fabrication, manipulation, and unpredictability on an A-F scale, caps the grade at D if any of three mandatory checks fail, and wires straight into CI with --min-score.
• Tech stack: Python CLI + pluggable LLM judges (OpenAI/Anthropic/Gemini/Azure/Bedrock/OpenRouter) + a Claude Code/Codex plugin
• Getting started: Medium — pip install ifixai gives you a full walkthrough against a built-in demo agent in one command, but auditing your own agent means writing a profile first (or letting your coding agent read the code and generate one) and lining up a judge API key from a provider other than your agent's own.

shiyu-coder/Kronos ⭐ 43k

GitHub　·　Python　·　MIT

• What it is: The first open-source foundation model family built specifically for financial candlestick (OHLCV) data. A two-stage pipeline first quantizes continuous K-line values into hierarchical discrete tokens, then pretrains an autoregressive Transformer on those tokens, using data drawn from more than 45 exchanges.
• Why it's worth a look: It's not an agent framework — it's a forecasting model that agents or quant pipelines can call directly. The paper has already been accepted at AAAI 2026, the mini/small/base checkpoints (4.1M to 102.3M parameters) are all public on the Hugging Face Hub, and there's a live BTC/USDT 24-hour forecast demo if you want to see it work before installing anything.
• Tech stack: Python + PyTorch + Hugging Face Hub (model and tokenizer weights)
• Getting started: Medium — KronosPredictor gets you a forecast in a handful of lines, but your input data needs to already be a DataFrame with the right columns (open/high/low/close, with volume/amount optional) and matching timestamps.

mcp-use/mcp-use ⭐ 11k

GitHub　·　TypeScript　·　MIT

• What it is: A fully-TypeScript MCP framework built on the official MCP SDK v2 that binds tools directly to React Views, so you can ship an MCP App with an interactive UI inside ChatGPT or Claude instead of a plain-text reply.
• Why it's worth a look: Most MCP server examples only show you how to call a tool and get back JSON. mcp-use wires Zod schemas, tool calls, and React Views into one type-safe pipeline, and ships with a built-in Inspector you can use from the browser or headlessly from the CLI. The project also publishes its own benchmark against FastMCP TS, the official SDK v2, and xmcp.
• Tech stack: TypeScript + MCP SDK v2 + Zod + React (Views) + built-in Inspector
• Getting started: Low — npx create-mcp-use-app@latest scaffolds a project, and npm run dev opens the Inspector in your browser with the full tool-plus-UI flow already running.

crestalnetwork/intentkit ⭐ 6.5k

GitHub　·　Python　·　MIT

• What it is: An open-source, self-hosted "cloud agent cluster" that lets multiple agents call and coordinate with each other as a managed service, rather than everyone running a pile of local agent scripts on their own machine.
• Why it's worth a look: It's deliberately designed so the agents themselves can never touch any of your secret keys — those stay on the server side. Compared to local-first agents (the README points at OpenClaw as the contrast), that cuts both the hardware requirement and the maintenance burden substantially. The project grew out of a web3/crypto context and keeps optional social-media and blockchain integrations, but the core agent-cluster design is industry-agnostic and works fine as a plain Python library too.
• Tech stack: Python + dual distribution as a PyPI package and a Docker image + optional Web3 integrations
• Getting started: Medium — importing it as a Python library is quick, but getting the full "self-hosted cloud cluster" experience means following the official deployment guide to stand up the service yourself.

Notable Releases

crewAI 1.15.29

Release Notes

• What changed: AgentExecutor graduated out of experimental status; a new offline eval/guardrail evaluation runner lets a crew grade itself in one command; a new Azure DocumentDB vector search integration landed; and tool calls now accept LiteLLM-compatible kwargs.
• Breaking changes: None called out in the release notes.
• What it means for you: If you're evaluating crewAI agents, you can now generate a scoring report with the built-in eval runner instead of wiring up a separate evaluation framework. The LanceDB filter-escaping fix also means that if your scope or id values ever contained special characters, queries could previously fail or return the wrong results — that edge case is now closed.

Pydantic AI v2.60.0

Release Notes

• What changed: RetryPromptPart is now formally deprecated in favor of ToolReturnPart(outcome='retried') and a new RetryFeedbackPart; content the harness injects into the "user channel" is now wrapped as <harness_data> instead of being disguised as a user message; and the MCP capability's default id is now derived purely from the server URL's hostname, so two servers on the same host without an explicit id now fail outright instead of silently colliding.
• Breaking changes: All three of the above are listed under the official "⚠️ Compatibility Notes" section — code that pattern-matches on RetryPromptPart's type needs updating, and any setup running two unnamed MCP servers on the same host will now error on startup rather than quietly clash.
• What it means for you: If you're connecting multiple MCP servers in pydantic-ai, check for any sharing a host without an explicit id and add one before upgrading, or startup will break. If your code checks retry status via RetryPromptPart, migrate to ToolReturnPart(outcome='retried') now, before it's removed outright.

Today's Takeaway

I used to think "auditing an agent" mostly lived in academic papers or internal enterprise review processes. Seeing ifixai ship it as a standalone open-source command you can drop straight into CI — on top of crewAI folding an eval runner into its core and Pydantic AI locking down the boundaries around untrusted input and shared-host MCP servers — made it clear that "verifying the agent actually did the right thing" is moving from "something you bolt on yourself" to a standard feature frameworks ship with by default.

References

• ifixai-ai/ifixai on GitHub
• shiyu-coder/Kronos on GitHub
• Kronos paper (arXiv)
• mcp-use/mcp-use on GitHub
• crestalnetwork/intentkit on GitHub
• crewAI 1.15.29 Release Notes
• Pydantic AI v2.60.0 Release Notes