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

标签:#t

找到 16254 篇相关文章

AI 资讯

Agent Framework RAG for Agents: Giving Your Agent the Right Context

This is Part 13 of my series on the Microsoft Agent Framework. You can read the original post over on lukaswalter.dev . In the previous article , we looked at workflows. Workflows make sense when the process itself needs structure: state, checkpoints, events, human approvals, and resumable execution. This post is the bridge from Agent Framework into RAG. I plan on doing a full RAG deep dive sometime later. The practical question for now is smaller: How do I connect an Agent Framework agent to private application knowledge without stuffing every document into the prompt? For agents, RAG is less about adding more text and more about giving the agent a controlled retrieval path. The agent should fetch the right context at the point where it needs it. Agents do not know your private data Your company documents, product catalog, tickets, rules, policies, runbooks, and internal knowledge base live outside the model. The model has generic knowledge. Your application has private knowledge. Treat those as separate systems. You can paste some private data into the prompt, and for a demo that may be enough. But this falls apart quickly: full documents are expensive to send repeatedly long prompts are fragile stale documents may sit next to current ones users may not be allowed to see every source long context still needs selection The last point is easy to underestimate. A larger context window lets you send more text. It does not decide which text is correct, current, relevant, or permitted. Do not give the agent all knowledge. Give it the right context at the moment it needs it. Retrieval owns that job. The minimal RAG shape The basic RAG loop is small: user question -> retrieve relevant chunks -> pass chunks to the agent -> agent answers using that context For documents, the longer pipeline usually looks like this: documents -> chunks -> embeddings -> vector store -> search -> retrieved context -> agent response Documents are split into smaller chunks. Those chunks are embe

2026-06-18 原文 →
AI 资讯

Preparing Specs for AI Coding Agents

AI coding agents now edit repositories, run commands, and produce branches. That makes the spec before the work more important: it carries the context, boundaries, and success criteria the agent needs. What a good coding-agent spec includes Specs are becoming more important because AI coding agents are no longer only answering questions. They are reading repositories, editing files, running commands, producing branches, and asking humans to review the result. That changes what a prompt needs to become. When an assistant only answers a question, a private prompt can be enough. When an agent changes a shared codebase, the prompt becomes an assignment. And an assignment needs more than good wording. It needs the right context, boundaries, examples, and a way to judge whether the work matched the original intent. That is the practical reason to prepare a spec before sending a coding agent into a repository. The spec does not need to be long. It does need to tell the agent what problem it is solving, what behavior should change, what must not change, and how the result will be reviewed. At minimum, a good coding-agent spec should give the agent five things: the context behind the task the behavior that should change the constraints the agent should preserve examples or scenarios that define correctness the validation evidence a reviewer should inspect This is the useful idea behind spec-driven development, behavior scenarios, issue templates, lightweight design docs, OpenSpec, GitHub Spec Kit, and many internal engineering proposal formats. The specific framework matters less than the shape of the spec: the agent should receive enough context to act, and the team should receive enough structure to review the result. The spec is not a nicer prompt. It is the prepared assignment between human intent and machine execution. Prompts are good at starting work. Specs are better at carrying it. A private prompt is optimized for immediacy. It lives in a chat session. It can inclu

2026-06-18 原文 →
AI 资讯

How to Integrate Apache Kafka with Spring Boot: A Production-Ready Guide

When a Spring Boot service needs to talk to another service without waiting on a synchronous HTTP call, message queues are the usual answer. Apache Kafka has become the default choice for this in most backend teams, but a lot of tutorials stop at a "hello world" producer and consumer that would never survive a real production load. Things like consumer retries, error handling, serialization of real objects, and graceful shutdown get skipped, and those are exactly the parts that page you at 2 a.m. In this tutorial, you will build a Spring Boot application that produces and consumes JSON messages over Kafka. You will configure a producer and a consumer, send a typed object instead of a plain string, handle deserialization errors so one bad message does not block your whole consumer group, and verify the whole thing works end to end. By the end, you will have a small but realistic messaging setup you can build on. Prerequisites To follow along, you will need: Java 17 or later installed. You can check your version by running java -version . A Spring Boot 3.x project. You can generate one at start.spring.io with the Spring for Apache Kafka dependency added. A running Kafka broker. The quickest way to get one locally is Docker, which the first step covers. Basic familiarity with Spring Boot, including how @Component and application.yml work. Step 1 — Running Kafka Locally with Docker Before writing any code, you need a broker to talk to. Running Kafka by hand involves Zookeeper, broker configuration, and a fair amount of setup, so you will use Docker Compose to bring up a single-broker cluster instead. Create a file named docker-compose.yml in your project root: services : kafka : image : apache/kafka:3.7.0 container_name : kafka ports : - " 9092:9092" environment : KAFKA_NODE_ID : 1 KAFKA_PROCESS_ROLES : broker,controller KAFKA_LISTENERS : PLAINTEXT://:9092,CONTROLLER://:9093 KAFKA_ADVERTISED_LISTENERS : PLAINTEXT://localhost:9092 KAFKA_CONTROLLER_LISTENER_NAMES : CONTRO

2026-06-18 原文 →
AI 资讯

I built Proofline because AI agents are getting too good at sounding finished

AI agents are getting very good at writing final reports. The problem is not only that they make mistakes. The problem is that sometimes they make mistakes with excellent presentation. Proofline is a 5-skill Markdown pack that catches fake-ready output before it turns into a release, handoff, public post, or "yeah, looks done". What Proofline does It is not trying to be another giant agent. It works as a review route after the agent produces a result: Reference Gap Ready Gate Reality QA Lean Pass Repair Report Compiler Each step asks an annoying but useful question: what is missing from the references, what was not checked, where did the agent pretend everything was fine, and what actually needs to be fixed? Who it is for Builders working with Codex-style agent chats, AI coding workflows, Markdown handoffs, and any process where "done" needs to mean more than a confident paragraph. Release: https://github.com/aisflows/proofline/releases/tag/v0.2.0-rc5

2026-06-18 原文 →
AI 资讯

Gas Optimization That Doesn't Break Security: Storage, Calldata, and the Traps

Gas optimization is satisfying. You shave a few thousand gas off a function and feel clever. But some optimizations trade away safety in ways that are not obvious, and I have seen "optimized" contracts that introduced vulnerabilities. Here are the gas wins that are genuinely free, the ones that cost you safety, and how to tell the difference. Where gas actually goes Before optimizing, know what is expensive. Storage operations dominate. Writing a fresh storage slot ( SSTORE from zero to non-zero) costs a lot; reading storage ( SLOAD ) is cheaper but still meaningful; computation in memory is cheap by comparison. So the highest-leverage optimizations are about touching storage less. Free win 1: cache storage reads in memory If you read the same storage variable multiple times in a function, each read is an SLOAD . Read it once into a local variable instead: // WASTEFUL: reads storage `total` three times function distribute() external { require(total > 0, "empty"); uint256 share = total / count; emit Distributed(total); } // OPTIMIZED: one SLOAD, two memory reads function distribute() external { uint256 _total = total; // single storage read require(_total > 0, "empty"); uint256 share = _total / count; emit Distributed(_total); } This is free in the sense that it changes nothing about correctness. The value is identical; you just read it once. Pure win. Free win 2: calldata instead of memory for read-only arrays For external function arguments you only read (never modify), calldata is cheaper than memory because it skips the copy: // memory copies the whole array into memory function process(uint256[] memory ids) external { ... } // calldata reads directly from the transaction data, no copy function process(uint256[] calldata ids) external { ... } Again, free. If you do not mutate the array, calldata is strictly better. Free win 3: storage packing Solidity packs multiple variables into one 32-byte slot if they fit and are adjacent. Order your storage variables so smal

2026-06-18 原文 →
AI 资讯

Building a browser diagram editor: which import/export formats actually matter?

Disclosure up front: I'm affiliated with diagram.now — I'm connected to the product. I'm posting this to get developer feedback on diagram import/export interoperability, not to pitch an install. Most teams I've worked with don't have one source of truth for their diagrams. They have: a few Mermaid blocks living in READMEs and Markdown docs, an old Visio ( .vsdx ) or Lucidchart file someone made two reorgs ago, a SQL schema that is secretly the "real" ERD, and a pile of screenshots pasted into docs and tickets. The diagram is rarely the hard part. The hard part is that the same diagram lives in five formats and none of them stay in sync with the docs they're supposed to explain. I've been working on diagram.now , a browser-based editor for technical diagrams — flowcharts, UML, ERD, BPMN, cloud/network architecture, mind maps, wireframes. It's a free browser editor with no signup to start. There's an optional Confluence app for teams that want diagrams editable inside Confluence pages, but that's intentionally not what I want to talk about here. I want feedback on the editor itself, and specifically on the interoperability story. What it does today Import/insert from Mermaid and SQL — paste a Mermaid graph or a CREATE TABLE block to start an editable diagram instead of a static render. Import Lucidchart and Visio .vsdx files — this is migration-oriented, and honestly the part I most want real-world files to stress-test. Export to PNG, SVG, PDF, or a URL. Templates/shapes for the diagram categories above. I'm deliberately keeping the Confluence side secondary. The thing I actually want to learn is whether the browser editor plus import/export is useful on its own. Where I'd love feedback Imports: Which format matters most to you — Mermaid, SQL→ERD, .vsdx , Lucidchart, or something else (PlantUML, draw.io XML, Graphviz)? If you've ever tried to migrate diagrams between tools, where did it break? URL export: Is a shareable diagram URL genuinely useful in your workflow (

2026-06-18 原文 →
AI 资讯

The Road Toward Mainnet: A Security-First Approach to XRPL Lending Protocol

Over the last several months, XRP Ledger (XRPL) has fundamentally shifted in how amendments move from concept to mainnet. Historically, amendment development was largely focused on functional correctness, performance testing, traditional security audits, bug bounties and independent validator testing as the last line of defense to catch security vulnerabilities. As XRPL continues to grow in complexity and the value secured by the network increases, we recognized that the previous model was no longer sufficient. Advances in AI are also rapidly reducing the cost of vulnerability discovery, making it increasingly important to identify issues as early as possible in the development lifecycle. With that in mind, we set out to establish a stronger, repeatable, defense-in-depth model that makes it increasingly difficult for critical vulnerabilities, consensus risks, and feature interaction bugs to reach mainnet. The result is a significantly higher bar for amendment activation that combines specification rigor, adversarial testing, multiple independent audits, attackathons with expert security researchers, AI-assisted security reviews and phased deployments. The Lending Protocol ( XLS-66 ) and Single Asset Vault (SAV) - XLS-65 are among the first major amendments to undergo this full review process, making them some of the most rigorously tested amendments in XRPL's history. They also represent some of the most significant new financial capabilities added to the XRP Ledger since 2012, introducing native primitives for lending and borrowing built around Single Asset Vaults. Together, the Lending Protocol and Single Asset Vault bring lending and borrowing capabilities directly into the core XRPL protocol, advancing XRPL's capabilities for Institutional DeFi. Lending Protocol Security and Quality Gates This report provides transparency into the development and security process behind one of the most financially complex features XRPL has ever shipped. As context, the Lending P

2026-06-18 原文 →
AI 资讯

From Camera to Cloud: Netflix’s Scalable Media Processing Pipeline

Netflix has detailed a cloud-based system for scaling camera file processing across global film and TV workflows. The pipeline handles ingest, validation, metadata extraction, and media transformation at scale using FilmLight API and distributed compute. It standardizes workflows across editorial, VFX, and color pipelines, improving consistency and reducing manual handling across productions. By Leela Kumili

2026-06-18 原文 →
开发者

Google Calendar finally has more color options for events

Running out of color options for events in Google Calendar shouldn't be an issue going forward. The previous limit of 11 predefined colors has now been expanded to give users access to up to 200 custom colors for individual events across the native Calendar web and mobile apps, and the Calendar API. This started rolling […]

2026-06-18 原文 →
开发者

The midterms are going to be a data security nightmare

One messy database is threatening to disenfranchise thousands or even millions of registered voters, while leaving even more at risk of intimidation or data breaches, in the name of solving a problem that barely exists. As the 2026 midterm elections approach, election and privacy experts are sounding alarms about the Department of Homeland Security's Systematic […]

2026-06-18 原文 →
产品设计

The Verge’s guide to Amazon Prime Day 2026

Amazon Prime Day 2026 lifts off on June 23rd and will hopefully deliver the best deals of the summer. We’ve been covering the most notable pre-Prime Day discounts happening, and come next week, we’ll be bringing you many more deals — ones we can’t tell you about just yet. As usual, expect to see price […]

2026-06-18 原文 →