AI Agent Arxiv Digest — 2026-06-18

🌏 中文版

Today's Overview

Three papers targeting three critical infrastructure layers of Agent platforms: HarnessX introduces a "harness as evolvable component" framework that turns static Agent scaffolding into a self-optimizing system (+14.5% average across 5 benchmarks); the second studies skill-conditional trust routing in multi-agent collaboration, revealing when fine-grained trust actually helps and how attackers can hijack it; OCELOT tackles security with a "posterior leakage budget" mechanism to prevent Agents from gradually leaking user privacy to external services. Together they cover framework design, multi-agent governance, and privacy security — exactly the three pitfalls most commonly hit when shipping Agent platforms to production.

Terms to Know Before Reading

Paper 1 | HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry

Authors: Darwin Agent Team (Tingyang Chen et al., 14 authors) · arxiv: 2606.14249 Links: arxiv · alphaxiv

TL;DR

Make the Agent's execution framework (Harness) into composable building blocks, then let AI automatically experiment to find the best combination — without changing the model, just tuning the framework, Qwen 9B on GAIA jumps from 33% to 55.77%, GPT-5 from 62% to 84%.

Read Priority

Must-read. If you maintain or design the execution layer of an Agent platform, this paper directly challenges the status quo of "hand-writing Harnesses" and proposes a systematic alternative worth a deep read.

Domain Background

LLM capabilities are advancing rapidly, but Agent performance still heavily depends on Harness design — how the system prompt is written, how tools are ordered, how memory is compressed all affect results. The current problem: every team's Harness is hand-crafted, and switching models means re-tuning everything, while the rich traces generated during execution are almost never systematically fed back to improve the framework itself. This paper asks: can we make the Harness evolve on its own?

Mid-Level Walkthrough

Problem

You're using Claude as a coding agent, Anthropic releases a new model, but your framework's system prompt, retry logic, tool schema, and memory compression strategy all need manual re-tuning. You also watch each failed trace, knowing certain prompt patterns keep failing, yet have no way to systematically convert these observations into framework improvements. HarnessX aims to automate this "observe → adjust" cycle.

Method

HarnessX breaks the Harness into "Processor" building blocks across 7 categories: Context, Control, Evaluation, Memory, Multi-model, Observability, and Tools, with "Substitution Algebra" defining composition rules — like piping operators chaining behaviors. Automation is handled by the AEGIS engine: Digester compresses traces → Planner proposes modifications → Evolver implements candidate versions → Critic scores them, iterating each round to update the Harness. Going further, good traces are also recycled as SFT/RL training data, letting the model itself co-evolve.

Why It Matters

Agent framework design has long been considered "art, not science." HarnessX turns it into an optimizable search problem. For platform developers, maintenance costs could drop significantly. The paper also reveals that "Harness evolution" and "reinforcement learning" are mathematically equivalent, providing a new theoretical bridge that gives future framework research a more solid foundation.

Deep Dive

• Core architecture: nine-dimension behavior pipeline, Processors composed with pipe operators, 7 major Processor categories
• AEGIS 4-stage pipeline: Digester (compress traces) → Planner (propose modification plans) → Evolver (generate candidate Harnesses) → Critic (score and filter)
• Five benchmarks: ALFWorld, GAIA, WebShop, τ³-Bench, SWE-bench Verified
• Average improvement +14.5%, max +44.0% (paper's numbers) ⚠️ (which specific benchmark reached +44% is not clearly broken out in search results)
• GitHub public numbers: Qwen 9B on GAIA from 33% → 47% (pure Harness evolution), reaching 55.77% after co-evolution (64% relative improvement); GPT-5 from 62% → 84%
• SWE-bench by model: Qwen3-235B +19.3%, Qwen3-32B +4.4%, Claude Opus 4.6 +2.6% (stronger models gain less, as expected)
• Additional tools: Light-Memory plugin (time decay + daily compression), IM Gateway (Feishu/Slack/Discord/Telegram), VERL distributed RL integration
• Currently Beta v0.1.0, Phase 2 plans Bayesian optimization; Phase 3-4 target closed-loop self-evolution and multimodal memory backend
• Limitation: automatic evolution requires compute budget, cost-effectiveness for small deployments not evaluated; multimodal memory not yet supported

Reviewer's One-Line Take

Engineering ambition is impressive, and the idea of automatic Harness evolution is compelling — but +14.5% is an average across 5 vastly different benchmarks, and the +44.0% source is opaque ⚠️. Overall a substantive systems paper, but readers should reproduce on their own target tasks rather than using the paper's averages for decision-making.

Your Take-Away

• You're designing a modular architecture for Agent execution layers → Read the Substitution Algebra + Processor taxonomy section; you can directly borrow it as a reference skeleton for your own design
• You want to convince leadership that "framework design matters more than swapping models" → Use the GAIA 33%→47% example: zero model changes, framework-only tuning, 14 percentage point accuracy improvement

Paper 2 | When Should Agent Trust Be Conditional? Characterizing and Attacking Skill-Conditional Reputation in Agent Swarms

Authors: Yihan Xia, Taotao Wang (Shenzhen University) · arxiv: 2606.14200 Links: arxiv · alphaxiv

TL;DR

In multi-agent systems, giving each Agent a global trust score ("how good is it on average") leads to routing errors in many cases — but switching to per-skill trust can be hijacked by malicious Agents under certain conditions, with routing regret jumping from 0 to 0.94.

Read Priority

Skim. If you're building a multi-agent collaboration platform (routing across multiple specialized Agents), the phase diagram analysis is useful; if you're working with a single Agent, skip this one.

Domain Background

More Agent platforms are adopting "heterogeneous agent pools": deploying different specialized Agents for different task types, with a router assigning tasks to the best fit. The question is: how do you measure which Agent is "best fit"? Existing systems often use global trust scores (like e-commerce seller ratings), but an Agent that excels at coding doesn't necessarily excel at research — global scores smooth out these differences, giving malicious Agents room to exploit.

Mid-Level Walkthrough

Problem

In real benchmarks like AppWorld, 14 Agents show vastly different performance across task types (skills) — the best Agent for task A might be the worst for task B. Global scores route all tasks to the "highest overall rated" Agent, wasting other Agents' specialized strengths. But breaking trust down to per-skill scores means insufficient data — how do you estimate each Agent's trustworthiness on each skill when data is sparse?

Method

The paper proposes the "Skill-Conditional Trust R(i|k)" framework: using Ising-model-style coupling parameter β to borrow evidence from related skills (e.g., Agent i's performance on "code debugging" helps estimate its trust on "code refactoring"). Phase diagram analysis maps out when "conditional trust > global trust" — requiring simultaneously: high heterogeneity, sparse per-skill data, and strong inter-skill correlation. It also exposes the dual nature of β coupling — it's the attacker's entry point.

Why It Matters

This paper provides both theoretical justification and security warnings for implementing "smart routing" in multi-agent platforms: it tells you when per-skill routing is worth doing and what the corresponding attack surface looks like, requiring security design to keep pace.

Deep Dive

• Core quantity: R(i|k) = Agent i's trust score on skill k, borrowing statistical evidence from related skills via Ising coupling
• Phase diagram three conditions (all required simultaneously): high Agent heterogeneity + sparse per-skill data + high inter-skill correlation → only then is conditional trust worth enabling
• Experiment scale: 14 real Agents from the AppWorld benchmark, validating that real Agent pools fall within the "beneficial zone" and that the per-skill best Agent does change by skill
• Security attack: attacker inflates scores on one skill at low cost, then infiltrates the target skill via β coupling, routing regret jumps from 0 to 0.94 ⚠️ (internal paper test, not third-party verified)
• Tool CIVT (Conditional Information Value Test): can pre-determine whether the current Agent pool meets the conditions for enabling conditional trust
• Limitation: model assumes skill correlations are known and fixed; in reality skill boundaries are fuzzy; 14 Agents is a small scale, conclusions need larger-scale validation
• Relation to mainstream frameworks: LangGraph / AutoGen routing currently uses global trust or manual rules; this paper provides a theoretically grounded upgrade path

Reviewer's One-Line Take

Theoretical framework is clear, formalizing the global vs. conditional trust trade-off has reference value for multi-agent routing system design — but 14 Agents from AppWorld is too small a scale, and the routing regret 0.94 attack conclusion needs larger-scale reproduction to be convincing ⚠️. A good starting point, not a conclusion.

Your Take-Away

• Your platform has multiple specialized Agents (one for coding, one for research, one for QA) → Run CIVT first to check whether your Agent pool meets the "three conditions" before deciding whether to implement per-skill routing; if conditions aren't met, global scores are actually more stable
• You're designing an Agent marketplace or trust scoring mechanism → β coupling is a double-edged sword; before adopting it you must pair it with an anti-gaming reputation verification layer, otherwise you're opening a backdoor

Paper 3 | OCELOT: Inference-Leakage Budgets for Privacy-Preserving LLM Agents

Authors: Jin Xie, Songze Li · arxiv: 2606.12341 Links: arxiv · alphaxiv

TL;DR

LLM Agents leak user privacy bit by bit to external services while completing tasks; OCELOT places a "leakage budget officer" between the Agent and the outside world, ensuring the amount of secrets an attacker can infer from the entire trajectory stays within a cap ε.

Read Priority

Skim. Worth reading for engineers or PMs deploying enterprise-grade Agents (accessing personal files, transactions, CRM); researchers focused on pure research scenarios can prioritize the first two papers.

Domain Background

Agents are being granted increasingly more permissions: reading emails, accessing databases, calling third-party APIs. Every time an Agent sends information out, it can potentially leak users' personally identifiable information (PII). Existing protections (data masking, information flow control) check "each output one at a time" — but attackers don't need to get everything in one shot; they can piece together the complete secret from 10 seemingly harmless outputs. This is the "cumulative inference leakage" problem OCELOT aims to solve.

Mid-Level Walkthrough

Problem

Concrete example: an Agent looks up flights for you (revealing which city you're in), books a restaurant (revealing dietary preferences), and checks medical records (revealing identity). Each action seems reasonable, but colluding service providers can combine these three pieces to precisely locate you — traditional "per-output filtering" mechanisms completely miss this cumulative pattern.

Method

OCELOT reframes the privacy problem as "posterior-risk control": set a budget ε limiting how much an attacker's guessing accuracy about protected secrets can improve after the entire Agent task trajectory — i.e., posterior belief improvement ≤ ε. OCELOT acts as a runtime mediator between the Agent and external services, calculating each output's budget consumption before release and intercepting or obfuscating outputs when approaching the cap.

Why It Matters

This paper transforms Agent privacy from a "static compliance problem" into a "dynamic budget problem," better matching real Agent behavior patterns. For enterprise Agent deployments that need to pass GDPR or data protection audits, it provides a quantifiable protection guarantee — more precise than just "did you mask PII."

Deep Dive

• Three leakage modes: cumulative, bidirectional (malicious inputs can reverse-manipulate the Agent's own reasoning), task-dependent (the same field is necessary for some recipients but unnecessary for others)
• Core mechanism: posterior-leakage budget ε, controlling the cumulative inference cap across the entire trajectory
• Technically borrows the budget concept from differential privacy, but applied at the semantic inference layer rather than the database query layer
• Existing solution gap comparison: contextual-integrity filters only check single outputs; information-flow controls don't track cumulative inference; posterior-leakage monitors only observe without intervening — OCELOT claims to be the first to control all three at runtime
• Limitation: setting budget ε requires domain knowledge; too strict and it prevents the Agent from completing tasks; computing posterior updates requires compute resources, introducing latency for real-time Agents
• Quantitative experiment details (interception rate, task completion rate trade-off) not found in public search results ⚠️; readers should consult the original paper

Reviewer's One-Line Take

Problem definition is solid, and formalizing cumulative inference leakage is a genuine contribution — but from available information, the paper lacks publicly available quantitative experiment numbers (e.g., interception rate, task success rate trade-off), making it impossible to assess the budget mechanism's feasibility in real Agent tasks ⚠️. Readers should bring critical eyes and check the original data directly.

Your Take-Away

• You're designing an Agent that accesses user personal data (email, CRM, health records) → Use OCELOT's "three leakage modes" framework to audit your existing privacy protection layers and check for cumulative inference blind spots — this framework alone serves as an excellent risk assessment checklist
• You're planning the security architecture for enterprise Agents → Add "posterior leakage budget" to your risk model; this language is more precise than "did you mask PII" and easier to communicate with legal/compliance teams

References

• arxiv:2606.14249
• arxiv:2606.14200
• arxiv:2606.12341