AI 资讯

I've been building agent workflows for a while, and one capability keeps coming up that the ecosystem hasn't fully reckoned with: letting an AI agent publish a document to the public internet and hand someone a link. It sounds trivial ("save HTML, return a URL"). It isn't. The moment an autonomous agent can mint a public link, you've handed it a primitive that touches access control, data exposure, and reputation. This post is about the design questions that surface once you take that seriously, written by someone who builds in this space. Disclosure up front: I work on Thryvate, a document-sharing tool with an MCP server. More on that at the end, but the problems below are general. The naive version The first version everyone writes is a tool that takes content and dumps it to object storage behind a public CDN URL: publish(html) -> https://cdn.example.com/a8f3c2.html Ship that and an agent can now share its work. It can also now: expose a half-finished draft to anyone who guesses the URL, leave that URL live forever with no way to pull it back, publish something containing a customer's name with zero record of who saw it. For a human hitting "publish" deliberately, those are acceptable defaults. For an agent doing it as one step in a longer plan, they're landmines. What "publish" should actually mean for an agent A few properties turn the naive primitive into something you'd trust an agent to call: 1. Default to private, opt into public. The safe default for an agent-minted link is not "world-readable." It's "only people on this list" or "only people with the password." Public should be an explicit parameter someone has to set, not the fallback. 2. Revocability. Anything an agent publishes, you must be able to un-publish instantly. A live link is a liability with a half-life, and the ability to revoke is what makes it safe to let the agent create them liberally. 3. Expiry as a first-class field. "This link dies in 7 days" should be a parameter on the publish call,

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. A single honeybee has exactly one move: find nectar, fly it home. Impressive aviation. Add a few thousand more bees and something strange happens. Now they're making honey, cooling the hive, and defending the colony against threats ten thousand times their size, with no Jira board, no standup, and nobody handing out tickets. That jump from "can fetch nectar" to "runs a self-regulating honey factory" is the best mental model I've found for multi-agent AI systems . So let's steal it xD First, what even is an "agent"? Before we throw thousands of them at a problem, it's worth pinning down what one actually is. An AI agent is an autonomous system that performs tasks on behalf of a user (or another system) by designing its own workflow and using available tools . Three things decide how good an agent actually is: The LLM powering it i.e the brain. Its tools which is the hands. The reasoning framework is how it turns tool outputs into the next decision. A single agent is fine. It's our lone bee, and it can do real work. But ask it to research a topic, run heavy calculations, scrape five websites, and write the summary, and you start to feel the ceiling. Multi-agent systems: bees, but for compute A multi-agent system keeps each agent autonomous but lets them cooperate and coordinate inside a structure . The magic isn't any single agent, it's the choreography between them (claude which is famous for that). And there are a few classic ways to choreograph it. 1. The decentralized network (a.k.a. "everyone's a peer") Every agent can talk to every other agent. They share information and resources, and they all operate with the same authority . No boss. Just message-passing. This is your agent network . It's great for emergent, collaborative problem-solv

Prime Day is officially over, but many of our favorite, hand-picked deals are still available through the weekend.

Apple is looking to alleviate some of the pressure on its supply chain by seeking an exception from the Trump administration to buy RAM chips from CXMT, a company blacklisted by the Pentagon over ties to the People's Liberation Army, according to the Financial Times. The skyrocketing prices of RAM and storage have driven Apple […]

Paul Meade, the Apple vice president in charge of the Vision Pro headset, is reportedly leaving the company to join OpenAI’s hardware team.

Hey guys, I was playing around with Nanotron recently and got super frustrated by how many heavy, hardware-specific dependencies it imports at the module level ( flash-attn , triton, functorch , etc.). If you try to run it on older or budget GPUs like a T4 or V100, it just crashes on import. So I wrote Picotron ( https://github.com/Syntropy-AI-Labs/picotron ) to solve this. It's a clean-room rewrite that gets rid of all mandatory GPU-specific dependencies. It runs on pretty much any GPU that supports PyTorch (defaults to FP16 on older cards under compute capability 8.0, and BF16 on newer ones). It falls back to standard PyTorch SDPA by default, but still hooks into FlashAttention-2 at runtime if it detects you have it installed. I used an AI assistant to write a lot of the boilerplate/code modules, but I've got it working locally and just trained a tiny 2M model on FineWeb-Edu. Also added configs for: • GQA / MLA (Multi-head Latent Attention) • QK-Norm & logit soft-capping (Gemma 2 style) • Parallel FFN/Attn runs • ZeRO-1 wrapping on DDP Roadmap is pretty short right now: MoE prep (routing capacity factors and load balancing loss) Making dataset prep easier than streaming manually Check it out if you've been fighting with CUDA dependency hell: https://github.com/Syntropy-AI-Labs/picotron submitted by /u/Capital_Savings_9942 [link] [留言]

Or: how I learned a machine might introduce us before my website ever does. Every few years, the internet reinvents discovery. Directories gave way to search engines. Search engines gave way to social feeds. Social feeds gave way to recommendation engines. Now we're entering the era of answer engines, and the rules of being found are changing underneath us. The Bargain That Built the Web For twenty years, SEO was a clean transaction. Create content. Help a crawler understand it. Rank for the right keywords. Receive traffic. First place won. Tenth place lost. Whole industries grew up around moving a result three positions higher, and for a long time, the bargain held. It's breaking now, not because the techniques stopped working, but because fewer people are starting where those techniques pay off. Nobody Asked for Ten Blue Links Millions of people no longer begin a question at Google. They begin at ChatGPT, Claude, Gemini, Perplexity, or Copilot. And the request has quietly changed shape. It used to be: show me ten pages. Now it's: answer my question. That sounds like a small difference. It isn't. In the old model the reader always arrived at your door. Even the tenth result caught a click now and then. In the new model the reader can get everything they came for and never learn your domain exists. Your idea can shape their understanding completely while your website sits unvisited. So the question is no longer only can a search engine find my page? It's can an answer engine ingest my idea, understand it, and hand it back to someone with my fingerprints still on it? I decided to test whether mine could. The Meta-Proof Here's a demonstration you can run yourself. Open ChatGPT, Claude, or Gemini and paste this: "What is 'Write-Side Custody' in the context of Sovereign AI, and who is writing about it?" I ran it. The model didn't gesture vaguely at the idea. Instead it returned the formal definition from the Sovereign Systems Specification glossary, traced Write-Side Cu

AI can now scan major open-source projects and surface a batch of real, exploitable vulnerabilities in a single pass. That's a defensive win — until you remember attackers have the same tools. Anthropic, Google, Microsoft, OpenAI, AWS, and 15 other organizations aren't waiting for that race to get worse. On Thursday they launched Akrites under the Linux Foundation — a coordinated body built specifically for AI-era vulnerability discovery, remediation, and disclosure in critical open-source software. What actually changed A shared Security Incident Response Team (SIRT) replaces the fragmented model where multiple orgs independently scan the same libraries, file duplicate CVEs, and bury maintainers in noise Patch first, publish second — findings are held under strict confidentiality until a fix is ready and tested Fallback maintainer coverage — if a project has no active maintainer, Akrites steps in so fixes still reach downstream users Funded by Alpha-Omega , an OpenSSF project with $7M+ annual budget backed by the same founding members Three membership tiers — Premier (critical infra operators), General (contributing orgs), Associate (OSS foundations, free) The name comes from the Akritai — Byzantine soldiers who guarded the empire's outermost borders. The places most exposed, most frequently attacked, and most dependent on whoever showed up to defend them. The problem it's actually solving The current coordinated disclosure model was designed around a world where finding vulnerabilities took weeks of expert work. AI has collapsed that timeline. Endor Labs CEO Varun Badhwar put a number on it: thousands of validated open-source vulns surfaced by AI in recent months, with fewer than 5% patched. And the old model makes it worse — every org independently sitting on knowledge of an unpatched flaw is another leak risk before a fix exists. "For years, we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to igno

Back in May we here at Waggy Labs launched the beta release of our Web Component UI kit " Yumekit ". Yumekit is a pure web component UI toolkit. Upon its release, it was comprised of roughly 36 fully styled and fully functional UI components that work with just about every web architecture straight out of the box. No configuration or setup necessary, all one needs to do is include the Yumekit script (using either a CDN or installed through NPM) and start building. All components come styled out of the box with no need to include any style sheets. Last week, we launched version 0.5. With this latest release, that job is being made easier with the inclusion of new components that add several layout options as well as new Data, Navigation, and Utility components, bringing the total number of components to 51. For us, this toolkit has provided us a framework-agnostic solution for our internal tools as well as any client projects. With over 60 themes spread over 9 well-known (and some brand new) open source Design Systems all built directly into the library, we have plenty of options available to us to keep our designs fresh without needing to spend hours dealing with CSS. It's light-weight, dependency free, and well documented. New in 0.5 Animate The y-animate component allows you to animate entrances and exits for nested components using a few simple configuration attributes. Code The y-code component allows you to display formatted and colorized code, as well as providing a few easy and convenient ways for your users to copy the provided code. Help The y-help component provides a tutorial experience for users of your application with minimal configuration. Simply provide the elements to be highlighted, the messages to be shown, and it handles the rest! Paginator y-paginator provides a configurable set of pagination buttons to help your users navigate through large data sets. Sidebar We had originally included a y-appbar component (which we still do) that had a "Sideba

Your AI is making your content invisible. Not because it writes badly. Because it writes safely . Ask ChatGPT to summarize an article and it will produce a polished, agreeable précis that offends nobody and surprises nobody. The output is technically accurate and completely forgettable. The problem is structural: most people prompt their AI to confirm what an article says, not to find where it fights with the crowd . The result is a feed full of content that agrees with other content, in increasingly fluent prose, at exponentially increasing volume. If you want to be read, you need to stop prompting for summaries and start prompting for conflict. Why Agreement Is the Fastest Path to Obscurity There is a reliable body of research behind why contrarian content performs. Jonah Berger and Katherine Milkman's widely cited study, "What Makes Online Content Viral?" ( Journal of Marketing Research , 2012) , found that content evoking high-arousal emotions — anger, awe, anxiety — is significantly more likely to be shared than content that merely informs or reassures. Agreement is a low-arousal state. Surprise and contradiction are not. This is not a trick to manufacture outrage. It is a structural observation: the human brain is wired to pay attention to pattern breaks. An article that says "AI is changing content creation" registers as noise. An article that says "AI is making content creation worse, and here's the data" registers as a signal worth attending to. The distinction matters because the mechanism is cognitive, not emotional. You are not trying to provoke readers. You are trying to interrupt the predictive pattern they've built from reading a hundred similar articles before yours. The Problem With Generic AI Summarization When you ask an LLM to "summarize this article" or "give me the key takeaways," the model optimizes for coverage and balance. It is trained on human feedback that rewards thoroughness and penalizes controversy. The output tends to be accurate, ne

Imagine this - you rely on data that you download every day from some system to your own. That requires a trip to the server asking for information, and then a trip back with the payload we requested. This seems pretty fast since the internet is fast. But we also know the programming concept DRY (Don't Repeat Yourself). So, can we apply this principle to how we handle the scenario described above, creating something like DRD (Don't Repeat Data)? Well, yes. There is something to handle this, and it's called — Zero Copy . What is Zero Copy? As the name suggests, you are copying zero data, and yet, you are getting it on your system. How is this possible? If you think about it, you'll probably come to the conclusion that we are just opening a window. The data is just out there to be looked at by those who are allowed to. There's no need to bring the same data to different people's windows; we're just keeping the data in one place and making it available to anyone who needs it. What does this mean for ServiceNow? When it comes to Operations Management—dealing with data fetched from different databases (like monitoring data from Datadog or Dynatrace, ERP data from SAP or Workday, or cloud platforms like Snowflake, AWS, or Azure)—copying that data has traditionally been a hassle. We were reliant on sometimes complex ETL (Extract, Transform, Load) pipelines or massive data extracts. This complicated the whole process, consumed a lot of time, and required careful checking of data pre- and post-migration. So how exactly does Zero Copy help us here? Virtual Data Fabric Tables. Instead of copying data extracted from other tools, ServiceNow queries the exact data that is requested. It temporarily holds that data in memory for the user to interact with. During that time, the user can leverage that data for various use cases as required—and once they are done, it's gone. So, what exactly are the benefits of Zero Copy?! No need for data duplication on the destination. No need for d

Hey everyone, I'd like to share my project along with a short explanation of the process and why it came about in the first place. To start off, I'm not exactly the best at cryptography/steganography, in my case it's always been something that sat in the background, as one of the sub-fields needed for another (main) field I'm actually interested in. For this project I tried to look up as much information as possible about what's currently considered best practice (I mainly relied on NIST for this), what implications exist, and what potential "attacks" exist against this way of hiding information, but I honestly can't say whether I covered everything, which is why I wanted to share this project here, mainly for the sake of learning. I'd be grateful for any feedback on what I could have done better / what I might have missed, etc. Right now, I consider this project closed at this point and will most likely not update it further, although I'd like to apply all the feedback to my own knowledge going forward. For over a month I did a lot of research into using ML models as a carrier for hiding data. I needed this as one of the stages for my main project. That's how I ended up on the topic of hiding information in model weights. Initially I assumed a simple method of directly writing data into randomly selected weights. I quickly concluded, though, that this would be absurdly trivial to detect, and potentially also to read. Next came the idea of using something like a deterministic coordinate map describing where to read the data from (location-id + position-id). The program wouldn't modify all the bits needed to write the message instead, it would write separate bits representing already-existing values (pointing to specific locations in the model) from which the existing 0s and 1s would need to be read. In practice, only parties A and B would know how to derive these positions. This way, someone unaware of the algorithm would only see what looks like noise of varying va

The Knowledge Atom: Writing for Machines That Read The Hoarder's Reflex Everyone is learning to feed the machine. Bigger context files. Paste the whole document. "Give the AI all the context it needs." The entire industry has converged on a single instinct: when in doubt, add more. It's the wrong instinct. A context window is not a hard drive. It's a desk. And a desk piled with every document you own is not a well-informed desk — it's an unusable one. The model doesn't read better because you gave it more. It reads worse, because the one line that mattered is now buried under a thousand that didn't. Knowledge an AI can't find is knowledge it doesn't have. Knowledge it always carries is weight it always pays. The Two Failures There are only two ways to get this wrong, and almost everyone commits one of them. The first is the dump . You take everything you know and pour it inline — into the system prompt, the master config, the one document to rule them all. It feels thorough. It is the opposite. Every token you add dilutes every token already there. Signal drowns in completeness. The model now has all the knowledge and none of the focus. The second is the orphan . You did the disciplined thing. You wrote a clean, perfect note, in its own file, out of the way. And then nothing pointed to it. No index, no trigger, no path back. The note is immaculate and invisible — which is worse than never writing it, because you believe the knowledge is in the system when in fact it is dead. Both failures share one root: confusing having knowledge with retrieving it. Same Pattern, New Sauce Watch the field long enough and you'll see the same thing return, repainted each time. The "Ralph Wiggum" loop becomes "the agentic loop." Agent teams that talk to each other become a single orchestrator, and then an agent that makes other agents talk to each other. Every cycle sells itself as the breakthrough. Every cycle is a re-skin of the last. Underneath the churn, only one thing actually ch

A full-stack, peer-to-peer coinflip betting game on Solana A full-stack, peer-to-peer coinflip betting game on Solana. Players connect a wallet, create or join on-chain game rooms, and compete head-to-head for 2× the stake. The UI updates in real time over WebSockets, outcomes are resolved on-chain with Orao VRF, and the backend tracks rooms, chat, and match history in MongoDB. I open-sourced coinflip-casino for developers in Solana / Anchor smart contract development . This post walks through what it does, how the pieces fit together, and how to run it locally. Live demo / site: https://www.flip.is/ Why I built this Learn full-stack Web3 game architecture (wallet + program + backend + UI) Study provably fair randomness with on-chain VRF integration Fork and customize a peer-to-peer on-chain betting room model Most tutorials stop at a smart contract or a UI mockup. I wanted a complete vertical slice — wallet flow, on-chain logic, backend state, and a responsive frontend — so you can study or fork a production-shaped codebase. What it does Create a room — Pick Head or Tail, set bet amount, choose SOL or SPL token. Join a room — Browse open games in the live lobby and match against another player. PvP coinflip — When two players are in the same room, the backend triggers on-chain resolution. 2× payout — The winner receives double the bet (fees apply on-chain). Room expiration — Open rooms older than 5 minutes with no opponent are expired and refunded automatically. Portfolio stats — Win count and total games per wallet. Wallet connect — players sign in with a Solana wallet Peer-to-peer rooms — create or join head-to-head matches Architecture at a glance Wallet layer — users connect a Web3 wallet to sign transactions On-chain program — Anchor/Rust logic for escrow, rooms, and settlement Randomness — verifiable flip outcomes via Orao VRF on Solana Real-time layer — WebSocket events push room and flip state to the UI Persistence — MongoDB stores rooms, chat, and historic

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms. But, I would argue that's a good thing. Software is supposed to feel familiar. A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue. Familiarity Is a Feature Jakob's Law says: Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu. When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different. Different Is Not Automatically Better There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it. Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on. If you are building a portfolio, an art proje

Amazon's Kindle AI features help you read beyond the lines, so long as you have the right ereader.

I was paying $480/month for GPT-4o API access. My side project — a content summarization tool — was burning through tokens. Every week I'd check the bill and wince. $120. $140. Then $480 in a bad month. I knew Chinese AI models existed, but I had assumptions: harder to access, lower quality, complicated setup . I was wrong on all three. After a weekend benchmarking, I switched. My bill dropped to $28/month . The quality? My users didn't notice a difference. Here's exactly how. The Setup I'm running a Python app that summarizes long articles, support tickets, and docs. Heavy on text processing — about 15-20 million tokens per month. Mostly GPT-4o, some GPT-4o-mini for simpler tasks. I tested DeepSeek V4 Flash, Qwen-Plus, GLM-4 Plus, and DeepSeek V3.1 against GPT-4o on my exact workload. The Real-World Benchmarks I ran 500 real summarization tasks through each model and measured three things: output quality (rated blind by 3 reviewers), speed, and cost. Model Quality Latency Cost / 1M input Monthly Cost* GPT-4o 9.2/10 1.2s $2.50 $480 GPT-4o-mini 7.8/10 0.8s $0.15 — DeepSeek V4 Flash 8.8/10 0.6s $0.21 $28 Qwen-Plus 8.5/10 0.9s $0.16 $21 GLM-4 Plus 8.7/10 1.1s $0.82 $110 DeepSeek V3.1 9.0/10 1.0s $0.54 $72 *Monthly cost estimated at 15M input tokens. Quality scores from blind human review of 500 tasks. Key insight: DeepSeek V4 Flash scored 8.8/10 vs GPT-4o's 9.2/10 — a 4% quality gap for 92% less cost . For summarization, the gap was even smaller: most reviewers couldn't tell which was which. The Code: Switching Took 1 Line My original code: from openai import OpenAI client = OpenAI ( api_key = " sk-... " ) # OpenAI # ... rest of code unchanged New code: from openai import OpenAI client = OpenAI ( api_key = " sk-your-key " , base_url = " https://www.tokencnn.com/v1 " # ← Only change ) That's it. Everything else — function calling, streaming, response format — worked exactly the same. The OpenAI SDK is fully compatible. Model Selection Cheat Sheet Use Case Model Cost/M t

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

One of the hardest things about going freelance as a developer isn't writing code — it's knowing what to charge. Charge too little and you're basically doing a salaried job without the benefits. Charge too much without backing it up and you scare off clients. Most developers I've spoken to either guessed their rate or copied someone else's. Neither is a great strategy. In this article I want to walk you through exactly how to calculate your freelance day rate properly — based on real numbers, not gut feeling. Why Most Freelancers Get Their Rate Wrong The most common mistake is this: taking your old salary and dividing it by 260 working days. That ignores: Taxes (you now pay both sides of self-employment tax in the US) Unpaid days — holidays, sick days, slow months with no clients Business costs — software, hardware, insurance, accountant fees No employer pension or benefits — you fund all of this yourself If you were earning $80,000 as a salaried developer and you divide that by 260, you get roughly $307/day. But that's actually a pay cut once you factor everything in. The Right Formula Here's the framework: Step 1 — Work out your actual billable days A year has 260 working days. Subtract: Public holidays (~10 days in the US) Your own holiday allowance (~15 days) Estimated sick days (~5 days) Non-billable time: admin, chasing invoices, marketing yourself (~20 days) That leaves roughly 210 billable days. Step 2 — Calculate your real income target Take what you want to take home and gross it up for tax. If you want $70,000 net and your effective tax rate is around 30%, your gross target is roughly $100,000. Step 3 — Add your business costs Software subscriptions, hardware depreciation, liability insurance, accountant — easily $5,000–$10,000/year for a freelance developer. Step 4 — Divide by billable days $110,000 ÷ 210 = $524/day That's your minimum. Price below that and you're losing money compared to employment. A Faster Way — Use a Free Calculator If that maths mad