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

标签:#Claude

找到 333 篇相关文章

AI 资讯

From kanban to harness: when the tracking tool becomes the orchestrator

When I shipped KittyClaw two weeks ago, the tool did one thing: serve as a board. The Claude agents ran alongside - first by hand, then via a dispatcher.mjs : a Node script polling KittyClaw's API, triggering the right agent based on who was assigned to which ticket. The dispatcher worked great. It orchestrated Aekan's 13 agents for weeks. But it was an external process : one more node dispatcher.mjs to launch, a state file ( dispatch-state.json ) to keep in sync, logs to dig up in .agents/channel/debug.log , a config to copy-paste across projects in JS. Today, the dispatcher doesn't exist anymore. Orchestration lives inside KittyClaw . I run dotnet run on KittyClaw, nothing else. Aekan's 13 agents still run - but the infra that drives them is now a first-class citizen of the board. This shift from "dispatcher on the side" to "dispatcher inside the board" is small in lines of code, but it completely changes what the tool is. And how I work. This piece documents KittyClaw , the kanban orchestrator at the center of the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), KittyClaw runs the AI agents that drive these projects in production. Before: two processes to run, two places to look The old setup was three stacked layers: KittyClaw - the board, with its UI and REST API. dispatcher.mjs - a separate Node script in the project's .agents/channel/ , launched manually in a terminal. Claude Code - the agents themselves, launched by the dispatcher. It worked. But every project had its own dispatcher.mjs , usually forked from Aekan and hand-adapted. Patterns duplicated: 30s polling, code lock, evaluator debounce, daily budget. Adding a feature (say boardIdle or subTicketStatus ) meant re-coding it in every dispatcher, or accepting that one project had it and others didn't. And visually, orchestration was invisible from the board . To see an agent's live activity, I'd pop a terminal, tail -f

2026-08-21 原文 →
AI 资讯

How to Create Your Own Claude Code Skill With SKILL.md

If you use Claude Code for frontend development, you may have noticed something. Claude can write code very fast. But sometimes the UI it creates looks too similar to other AI-generated websites. You get the same rounded cards, large headings, soft shadows, gradients, and simple layouts. The code works. But the design does not always feel like your own. Hi everyone, I am Henry. In this article, I want to show you a simple way to fix that. We are going to create our own Claude Code Skill using a SKILL.md file. You do not need to build a complicated tool. You just need a clear set of instructions that Claude can follow when working on your frontend. What Is a Claude Code Skill? A Claude Code Skill is a reusable set of instructions for a specific type of work. For example, you can create a skill for: Frontend design Testing Documentation Code review Database work DevOps UI accessibility For this tutorial, we will create a frontend design skill . Our goal is simple: Help Claude create clean frontend UI without falling back to the same generic design patterns. Instead of writing the same design rules in every prompt, we can keep them inside a skill. Step 1: Create the Skill Folder Open your project in the terminal. Create a .claude folder if you do not already have one. Then create a skills folder: mkdir -p .claude/skills/frontend-design Now create the skill file: touch .claude/skills/frontend-design/SKILL.md Your project should now look something like this: your-project/ ├── .claude/ │ └── skills/ │ └── frontend-design/ │ └── SKILL.md ├── src/ ├── package.json └── README.md The important file here is: SKILL.md This is where we will put our instructions. Step 2: Write Your SKILL.md Open the file: code .claude/skills/frontend-design/SKILL.md Now add the following: --- name : frontend-design description : Build clean, responsive frontend UI with simple and consistent design rules. --- # Frontend Design Rules Before writing UI code: 1. Understand the purpose of the page. 2.

2026-08-20 原文 →
AI 资讯

Driving DaVinci Resolve's Free Edition with Claude, From Inside the App

The wall Every MCP server that controls DaVinci Resolve connects to it the same way: a script running outside the app calls into Resolve's scripting API over the network. That works fine on Resolve Studio. On the free edition it doesn't work at all — Lite is sandboxed and blocks any script that isn't launched from inside Resolve itself. The one door left open Free Resolve still runs Python scripts launched from its own Workspace > Scripts menu. A menu script gets the resolve object injected for free, can run a long-lived loop, and — because the sandboxed app ships the com.apple.security.network.server entitlement — can open a localhost listening socket. That's the whole trick: the MCP server is the menu script. Claude Code ──HTTP JSON-RPC (MCP)──▶ 127.0.0.1:8765/mcp │ server runs INSIDE Resolve │ (Workspace > Scripts > Utility) ▼ command queue → main script thread ▼ global `resolve` object → Resolve API What it gets you 157 tools across editing, color, render, media pool, and Fusion title styling — driven from plain-language requests in Claude Code. Zero dependencies: pure Python standard library, so there's nothing to pip install into Resolve's bundled interpreter. Try it git clone https://github.com/2sem/davinci-resolve-lite-mcp.git cd davinci-resolve-lite-mcp ./install.sh macOS only for now. Full tools reference and demo video in the repo.

2026-08-20 原文 →
AI 资讯

A 2-Token Prompt and a 39,966-Token Bill: Measuring What My Agent Actually Costs

There is a small cluster of posts going around right now about auditing your LLM invoice, and about how cost calculators get the numbers wrong. I went to check mine and hit a problem before I got to the arithmetic: my pipeline doesn't produce an invoice, and the plumbing I built two months ago is the reason why. This project has a script, git_commit.py , that turns a staged git diff into a Conventional Commit message. It shells out to the Claude CLI. There is no ANTHROPIC_API_KEY anywhere in the project, on purpose — an early version used urllib against the API directly and broke immediately for anyone running on an OAuth session instead of a raw key, so every AI call in the repo goes through a claude -p subprocess instead. That decision is still right. It also means there is no API key, so there is no per-key usage dashboard, so there is no line item to audit. For several months this script has been making a model call on essentially every commit, and I have never once known what any of them cost. The call site throws the numbers away Here is the actual invocation, trimmed: raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , env = _claude_subprocess_env (), ) subprocess.check_output returns stdout. With the CLI's default output format, stdout is the commit message string and nothing else. Every number I would want — tokens in, tokens out, dollars — is computed on the other side of that call and then discarded, because I asked for a string and a string is what I got. This is the part I want to flag for anyone wiring up a headless model call the same way. It isn't that the metering is missing. It's that the default output format is lossy in exactly the dimension you'd later want to audit, and you won't discover that by reading your own code, because your own code looks fine. It asks for text, it gets text. The fix is one flag: raw = subprocess . check_output ( [ " claude " , " -p " , " -

2026-08-19 原文 →
AI 资讯

Anthropic Expands Scientist Access to Frontier Models Through a Staged Biology Program

Anthropic is building a staged access path for life-science researchers to use its frontier AI systems. The company says Mythos 5 will initially be deployed to a restricted group of biology researchers under altered cybersecurity safeguards, followed by a broader trusted-access program as its protections improve. The move gives formal structure to researcher access while recognizing that advanced biology capabilities require governance beyond a standard product rollout. The most concrete details appear in Anthropic's Claude Fable 5 and Mythos 5 announcement . Anthropic says it intends to enroll a small number of researchers from life-science organizations working across fundamental and translational research. It also states that biology-research access will expand over time, contingent on stronger safeguards. This is not simply a broad public release for scientific users. Anthropic's approach separates access to highly capable life-science systems from its general product availability, creating an initial cohort and a planned trusted-access route. That distinction matters for institutions that want to assess how frontier models may fit into research workflows, procurement processes, and internal AI governance. A staged route to biology research access Anthropic's confirmed plan centers on Mythos 5, a model in the company's life-sciences-oriented Mythos and Fable line. The initial deployment is limited to a restricted set of biology researchers, and Anthropic says cybersecurity safeguards will be lifted for that cohort. The company frames the program as an early step, rather than a final availability model, with broader access intended as safeguards mature. Access pathway Who it covers What Anthropic has confirmed Initial Mythos 5 deployment A restricted set of biology researchers Cybersecurity safeguards will be lifted for the initial cohort. Planned trusted-access program Biology researchers beyond the initial cohort Anthropic plans to broaden access over time as s

2026-08-19 原文 →
AI 资讯

Claude Enters Live Life Sciences Workflows With Early Lab Results From Anthropic

Anthropic has published early evidence of Claude operating in live life sciences research workflows , moving the discussion beyond generic claims about AI-assisted science. Its January 15, 2026 report describes deployments at Stanford and MIT labs where Claude has been used for data-heavy analysis, experimental design and hypothesis generation. The results are promising, but they are best understood as case studies of lab-scale use rather than proof that AI can independently conduct scientific research. The work is centered on Claude for Life Sciences , an expanded capabilities suite that Anthropic says includes improvements in Opus 4.5, access to more than 60 databases, and genomics, proteomics and cheminformatics toolkits. In Anthropic's official report on accelerating scientific research , the company presents examples from several research groups that used Claude within existing scientific processes. The important development is not simply that researchers asked a general-purpose model scientific questions. The reported deployments connect Claude to structured scientific resources and lab-specific workflows, where scientists can assess its output against experimental context, domain knowledge and, in some cases, planned validation work. That makes the report relevant to research organizations evaluating where AI can reduce analytical friction without displacing human scientific judgment. What Anthropic's lab case studies show The case studies cover different points in the research process. Together, they illustrate where Claude may be useful: organizing and interpreting complex evidence, proposing options for researchers to assess, and accelerating work that would otherwise require substantial manual effort. At Stanford's Biomni project, researchers used Claude in genome- and data-heavy workflows. Anthropic reports that an early trial included molecular cloning design and analysis across large, multi-source datasets. The lab cited examples of tasks being complet

2026-08-19 原文 →
AI 资讯

Codex Maxxing: The Copy-Paste Skill I Use to Ship with Agents

Codex maxxing started as a joke about using more agents. I have started treating it as a skill instead. I use Codex for implementation, research, repository audits, planning, and writing. The hard part is no longer getting an agent to produce a first draft. The hard part is turning more capacity into work I can inspect, explain, and safely keep. Jason Liu's original Codex-maxxing essay made the broader idea click for me: Codex can become a durable workspace rather than a one-shot coding prompt. I wanted to turn that idea into something a reader could actually install. So this post contains a skill. Not a collection of clever prompts. A small routing layer that decides when to work directly, when to ask questions, when to investigate, when to plan, and when to bring in a fresh reviewer. Why a skill instead of another prompt? A prompt disappears into the task that used it. A skill gives the workflow a name, a trigger, and a repeatable contract. The contract I wanted was simple: keep the user's request authoritative; treat attached files and reference material as evidence, not hidden instructions; inspect the repository before guessing; route ambiguity before execution; give every worker a bounded handoff; require proof instead of trusting a completion message; leave stable lessons where the next task can find them. That combines the useful parts of the skills I already use. deep-interview is good at exposing missing requirements. deep-dive connects causal investigation to those requirements. omc-plan draws a boundary between planning and execution. The new skill sits above them and chooses which lane fits the task. That is the part I was missing: not another worker, but a traffic controller. The workflow in plain English Codex Maxxing runs a capacity-to-proof loop: Preflight. Restate the outcome, inspect the repository, and separate facts from guesses. Route. Choose direct work, an interview, a causal investigation, a plan, or approved parallel execution. Packet. Defi

2026-08-18 原文 →
AI 资讯

The Status Quo of AI in Software Development (2026)

Artificial Intelligence in 2026: From Companion to Infrastructure Artificial Intelligence has moved from being a futuristic concept to an everyday companion in software development. In 2026, the landscape is defined by rapid innovation, fierce competition, and unresolved challenges around governance, sustainability, and labor. Developers today are navigating both unprecedented opportunities and complex risks. Industry Dominance Over 90% of notable AI models now originate from industry rather than academia, signaling commercialization as the primary driver of innovation. Research labs continue to contribute breakthroughs, but the pace of deployment is overwhelmingly shaped by corporate priorities, venture capital, and cloud infrastructure. Geopolitical Competition The United States leads in model releases and data center infrastructure, while China dominates robotics and research output. This rivalry shapes the pace and direction of AI development. Europe has carved out a niche in regulation, with the AI Act setting global standards. Emerging economies in Africa and India are focusing on applied AI, building tools for agriculture, education, and healthcare. Compute Explosion Global AI compute capacity has grown more than threefold annually since 2022, powered largely by Nvidia GPUs. Data centers now consume nearly 30 GW of electricity — comparable to the peak demand of New York City. This raises urgent questions about sustainability and the environmental cost of progress. The ChatGPT Moment Artificial Intelligence has had many waves, but the one that truly captured global attention was the release of ChatGPT. What began as a conversational model quickly became a cultural phenomenon, reshaping how people interact with technology, learn, and even work. Disruption : It challenged traditional search engines, productivity tools, and educational practices. Social Acceptance : Within months, it was integrated into classrooms, offices, and personal devices. AI was no longer

2026-08-17 原文 →
AI 资讯

One terminal, two trust levels — running Claude Code against a real subscription and a cheap proxy

Part of an ongoing series on model routing and trust tiering for agentic coding tools. This one's the boring, working half — no bug hunt, just a setup that's been running clean across two machines. The problem Claude Code does one thing well: careful, scoped edits with a real plan-then-execute loop behind them, backed by a subscription you're already paying for. Not every task needs that. Exploratory reads, "summarize this directory," draft-and-discard scratch work — most of that doesn't need the most capable model watching every token. The fix is a second, cheaper backend for that category of work. The catch: Claude Code only speaks Anthropic's Messages API. It has no built-in notion of "same tool, different model." So the question is how to point it somewhere else without giving up the interface. The stack Trusted agent: claude — real Anthropic subscription, default session Cheap agent: claude-cheap — same CLI, routed through a self-hosted proxy Proxy: LiteLLM, translating Anthropic-format requests to DeepSeek V4 (pro for Sonnet-tier calls, flash for Haiku-tier) served through an OpenRouter API Transport: a persistent SSH tunnel from a small VPS back to each machine The proxy itself wasn't new. It's the same LiteLLM instance already routing a separate content pipeline I run. The actual work here was wiring Claude Code to it: a shell function and a few environment variables. The core trick and it took me a few week to learn this is to point ANTHROPIC_BASE_URL at LiteLLM's /v1/messages endpoint, not the OpenAI-compatible path LiteLLM also exposes. Claude Code only understands the Anthropic shape, so the OpenAI-shaped endpoint fails in ways that look like a client bug and aren't. Once LiteLLM sits on the right endpoint and translates underneath, Claude Code has no idea it isn't talking to Anthropic. The one bug worth flagging Claude Code's Plan Mode attaches a context_management parameter to its requests. Anthropic's API handles it. Most other backends don't recogniz

2026-08-17 原文 →
AI 资讯

Four Failures That Made a Weekly launchd Job Actually Run

Every skill my AI setup learns lives in one folder on my laptop — and none of it reaches the repo I created yesterday. That gap is why I built a weekly job that pushes my accumulated skills into every project on the machine. This is what it does, and the four failures I hit getting it to run unattended. Why this mechanism works Claude Code's ~/.claude/skills/auto/ is essentially a personal "habits library." Workarounds, completion criteria, and verification commands discovered mid-task get written out to skill files automatically by the AI, and can be referenced immediately on the next request — that's how the mechanism is designed. Reality is a little different, though. Skills keep piling up in .claude/skills/auto/ . But a project in a freshly created git repo, a side-gig job opened for the first time in weeks, a set of tools written in another language — those don't have the skills at all to begin with . Unless a human copies them by hand, or I type "refer to that skill" every single time, the habits I so carefully accumulated are completely dead in other projects. The structure of the problem looks like this. Skills accumulate in one place, .claude/skills/auto/ (global) They're actually referenced only "when that project has .agents/ or .claude/skills/ " (local) That bridging doesn't happen each time you create a new project (zero start) This isn't "growing your environment," it's "regrowing it every time." Once monthly revenue crosses a certain line, the number of concurrent jobs rises, and there are weeks where I cut two or three new repos. Each time, noticing the missing skills, copying manually, verifying — that work quietly eats time. Not the duration of a single tool call, but the opportunity cost of "if that skill had been here, this would have taken three minutes." The weekly auto-distribution script solves this. Early every Sunday morning, it scans all git repositories and pours the skills in. Without a human doing anything, the project you open on Monda

2026-08-17 原文 →
AI 资讯

Claude Code Auto Mode Goes Default August 14

On August 14, 2026, auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max and Team plans. The agent stops asking before each step and simply proceeds, unless the action it wants to take is judged irreversible, destructive, or aimed outside your environment. Anthropic's argument for the change is a number from its own testing: in a 1,053-action study, auto mode blocked 89% of harmful actions, while humans clicking through approval prompts caught 13.6%. The uncomfortable half of that finding is why — users habitually approved 97% of the prompts they were shown. If you have used a coding agent for more than a week, you already know the feeling being described. The prompt stops being a decision and becomes a keystroke. Anthropic calls this permission fatigue, and it is making the case that a model checking each action against a policy is a better guard than a human who has stopped reading. What changes on August 14, and what does not Three things are true at once, and they get mixed up in most of the coverage. First, the default flips only for new sessions on Pro, Max and Team . Existing sessions keep the mode they are running in. Second, auto mode is not "approve everything." Actions classified as irreversible, destructive, or targeting something outside your environment still stop and wait for you. Deleting data, force-pushing over history, and reaching for a remote system you did not point the agent at are the shapes of action that still surface a prompt. Third, the rollout ships with two controls that matter more than the default itself: prompt-injection screening on incoming content, and hard deny rules you configure so that certain actions can never be taken regardless of what the model concludes. Deny rules are the part worth your afternoon. They are the only control in the list whose behaviour does not depend on a model's judgement. The 89% number cuts both ways Eighty-nine percent blocked means eleven percent not blocked. On a s

2026-08-16 原文 →
AI 资讯

Claude Impact Lab LA: Community Changed the Code

Eighty minutes into building with three people I had met that morning, I renamed the idea I brought with me. 21:05 Rename the product to Civiq and credit the team I wrote that commit message myself. By then the idea had four authors. Some context on the room. The Claude Impact Lab is part of Claude Community, the run of local events where people who use Claude get together in person. This one followed a Claude Conversation held earlier in Los Angeles, where people talked through what AI is doing to their jobs. The Impact Lab takes what came out of that conversation and turns it into a build day. You get the problem brief, you form a team, you have the day, you demo at the end. Travis Johnson, a Claude community ambassador, hosted with Evan Grenda at Intersections LA. Developers and non-developers both, and they meant it. What I brought was not a project. It was an idea and a spec for it. No code, nothing built, nothing running. The idea comes out of something that is true in most cities. Your city government publishes what it intends to do before it does it. Agendas go up ahead of the meeting, and any resident can read them, show up, and speak on an item before the vote. That right exists. Using it takes work, which is probably why every time I used it I would give up on what I was looking for. In Ventura it means 21 separate boards and commissions, each with its own page, posting PDFs that run long and read like they were written for the people already familiar with the subject matter. Because they were. So if you want to know whether anyone is voting on something a block from your house, you go looking, board by board, document by document. And you have to already know the words the city uses for the thing you would call a pothole. Agenda Watch was going to make all of that searchable in plain language, with every answer carrying a receipt back to the page it came from, so nobody has to take the tool's word for anything. In use that is a small thing. You ask a que

2026-08-16 原文 →
AI 资讯

Don't Hand Your Inbox to an Agent

A Reddit thread on connecting Claude Code to a Yahoo Mail account turned into a solid field guide for scoping down what an AI agent is allowed to touch. Here's the distilled version. Don't give Claude Code your Yahoo password or unrestricted mailbox access. The risk isn't only the password leaking, it's that an agent with full access can read private messages, attachments, recovery details, and information about other people, all in the course of doing something mundane. Why "just connect it" is the wrong instinct The thread's most-quoted line frames the problem well: people are casually handing agents the keys to everything at once. People are talking about just giving ai agents access to their entire devices LOL. Emails, passwords, bank accounts like what. The concern isn't that the agent will maliciously steal your data, it's that broad access creates exposure you didn't intend, every time the agent reads something to complete an unrelated task. The issue isnt really theft its exposure. And exposure scales with trust you've already granted, not with anything going wrong: It's all based on trust. Safer ways to connect it 1. OAuth over password Use a connection method where Yahoo shows you exactly what's being requested and lets you revoke it later. Never type your Yahoo login directly into the agent. 2. Least access, read-only Point it at a separate, low-value mailbox if you can. Avoid granting send, delete, forward, or account-settings permissions; the agent shouldn't be able to act as you. 3. Keep credentials out of the agent The safer pattern is a credential vault the agent calls out to, so it can request an authenticated action without ever seeing the raw secret. Before you connect anything ✅ Strip sensitive mail first. One commenter's habit: swap real details for placeholders and dummy data, then substitute the real values back in once the model's output comes back. ✅ Use a throwaway or secondary account. Never connect the address tied to banking, password re

2026-08-16 原文 →
AI 资讯

Most glassmorphism is blur + a white overlay. I extracted the actual refraction into a Claude Code skill

Every glassmorphism snippet I've seen is backdrop-filter: blur() plus a white overlay. That's a blurred rectangle. Real glass bends what's behind it, hardest at the edge — and that part is missing everywhere. Built it for a production Angular app, pulled it out as a Claude Code plugin: https://github.com/stormaref/LiquidGlassSkill /plugin marketplace add stormaref/LiquidGlassSkill /plugin install liquid-glass@stormaref-skills The refraction: bake a displacement map into a canvas, wire up feImage → feDisplacementMap → feGaussianBlur , point the element at it with backdrop-filter: url(#filter) . Since it's a backdrop filter, the input is the live page behind the element — so it tracks scroll, theme and content changes with nothing to invalidate. Field ported from liquid-glass-js (MIT, credited), minus its html2canvas snapshot. Why it's a skill and not a gist — four rules, each of which fails as plausible-looking output: Glass needs a backdrop. Over a flat page it reads as a gray box, which sends you reaching for more blur — the exact move that kills it. The tint is colorless. Hue in the tint fights the hue coming through; the surface goes muddy. Children of a glass panel paint no surface. An opaque fill covers the refracted backdrop, which is the whole effect. You can't feature-query it. Safari parses backdrop-filter: url(#…) and paints nothing, so @supports says yes and your panel is blank. Gate on engine. The CSS is 200 lines. Knowing that #1 is why your glass looks nths of things looking subtly wrong. MIT. Happy to talk displacement math — the 128/255 ≠ 0.5 decly long to find.

2026-08-15 原文 →
AI 资讯

0 of 3 Articles Published for 3 Days Straight: The 41-Second Timeout Margin That Killed My Automation

For three mornings in a row, my audit log printed the same line: published today: 0 / target: 3 . Nothing crashed. The scripts ran, exited, and produced nothing. The entire cause turned out to be a 41-second margin — a 300-second timeout against a process that actually takes 259 seconds. Changing one number to 600 turned 0/3 into 3/3 the next morning. Some background: I went from earning 100k yen a month as a university student to 600k a month juggling multiple gigs, then lost all of it overnight to a company-initiated layoff. Over the following six months I built an autonomous Claude Code environment, and I'm now above 1.2M yen in monthly revenue. At the core of it is a system that publishes three affiliate articles every morning without a human touching anything. Why this system works The difference between people who keep earning from affiliate marketing and people who drop out is not writing skill, and not a nose for picking products. It's whether you can keep going . Articles that tend to earn on Rakuten Affiliate share a common pattern: spec-comparison articles about home appliances and gadgets priced above 50,000 yen, with lots of reviews and in stock. Robot vacuums, portable power stations, heat-pump washer-dryers, fully automatic coffee makers. The search intent is "I want to compare before I buy," so product link click-through is high and it fits the structure of affiliate marketing well. The problem is cost. Researching the specs of a high-ticket appliance on the web, building a comparison table, and finishing an article good enough to include the "honestly weak points" section takes 30 to 40 minutes. Three articles is close to two hours. Almost nobody has the willpower to repeat that 365 days a year. I don't either. What you need here isn't "trying harder" — it's an environment that keeps running even when you don't try hard . Once the system is built, the running cost is just API calls. The affiliate-factory I built is a simple structure made of four sh

2026-08-15 原文 →
AI 资讯

Persistence of Memory, Personality, and Self in AI Agents The Someone That Persists, Session After Session, Across Months

A research announcement from a working multi-agent operation. Full paper to follow. A word first, on spirit. I am not a scientist, and none of this was done in a laboratory. It came out of my own work, something I built to get a job done and then could not stop looking at. Nothing here is a knock on the companies whose tools I use. What they have built is remarkable, and it is getting better by the day. I am not testing their systems to find fault. I am testing them to learn how each one handles the persistence of memory, personality, and self across sessions, in a single-agent and multi-agent design. If you build with these tools, the next paragraph is familiar ground. If you don't, it is the ground everything else here stands on. Here is one example of how an AI agent currently works by default and what the system I built changes. Every conversation runs inside a context window, a session with a token limit, billed against your online subscription account. At the start of a session three files load: the root file, a room file that tells the agent who it is, and a memory file which is capped at 25,000 characters, or 200 lines, a limited index. All of them load automatically. The memory file is really the only constant reference the agent has to past sessions, and it provides pointers to a folder of one-line notes, but no rule or hook makes it read the notes. Going deeper is left to the model, and often it doesn’t. The notes sit referenced but unread while the agent answers from what’s already in front of it in the current session. After that the model, the raw AI engine, keeps nothing between turns; each turn the model re-reads the whole conversation from the top and rebuilds its understanding from that. The software that holds this conversation and runs the model’s tools is the harness, and every commercially available AI system has one. As the session fills, the platform summarizes it, and the agent understands less, a kind of attenuation, the way an audio or vid

2026-08-15 原文 →
AI 资讯

Notes to Self: The Interview Between an Issue and a Spec

On 1 August I opened an issue that was three sentences long. A hundred and one minutes later the feature was merged, and the document that got it there ran to 457 lines . I didn't write those 457 lines. In fact, I didn't have to write any more documentation, and not because I simply allowed Claude to run amok. Here is the issue in full — control-api#265 , 225 characters: control-api#265 — Manifest-backed dashboard feeds For each dashboard, auto create a manifest keyed by dashboard_id. For each sensor the dashboard uses, tag it to be included in the manifest. When a dashboard definition is updated, add / remove tags from sensors accordingly. From that genesis moment, this is the lifecycle of the issue all the way through to landing: Time (UTC) Event 14:25 Issue #265 opened — 225 characters 14:54 FEAT-0007 spec committed — 457 lines 15:35 Spec merged (PR #266) 15:51 Implementation committed 16:06 Implementation merged (PR #267, 15 files), issue closed The interesting part isn't the speed. It's the step at 14:54 that landed a previously non-existent spec document, and what happened in the twenty-nine minutes before it. The issue was never a specification I often write issues like this one...the way most people write shopping lists. Actuator address is not ensured? Baseline the trace correctly. With the pre-rolls, the frame-rate looks out. They're abbreviated to the point of being cryptic to everyone else. I write them this way deliberately: I'm usually mid-something else when I notice a problem, or have an idea for a better route to the solution. The cost of a full write-up right at that moment would be a fractured sense of flow. As most engineers will tell you, the transitions into and out of flow are the most disruptive parts of their working day. This terse form of issue-writing can be all you need, and it's worth being precise about why it works and the trade-offs it includes. It is not because "the issues are good enough". They aren't. When you pick one of these u

2026-08-14 原文 →