Discover the new open-source watermark removal mini-program that's completely ad-free. Save watermark-free videos from social platforms quickly and efficiently.
Learn practical optimization strategies for the antigravity AI tool, including prompt engineering, MCP protocol integration, and choosing between Gemini Flash, Claude, and Gemini 3 Pro.
Get free access to Google's Gemini 3 Pro AI model with the Chrome Extension Gemini Nexus v3.0, featuring OCR, text selection tools, and customizable interface.
Technical analysis of integrating Claude Code dedicated channels into CCR system, addressing API compatibility challenges and token optimization strategies for AI developers.
Explore the top AI programming solutions: dedicated IDEs, plugins, and CLI tools. Find the best AI coding assistant for your development workflow.
Discover reverse engineering techniques to access free AI models including Claude, Gemini Pro, IFlow and Qwen. Essential guide for developers and researchers.
Discover a breakthrough compression algorithm for Apple II high-resolution graphics that optimizes storage while preserving quality, with insights for retro computing and modern image processing.
Innovative pure silicon programming demo uses only 4,000 logic gates instead of traditional CPU/memory, showing potential for simplified hardware design in AI and autonomous systems.
作者因个人需求，经常需要保存短视频平台的无水印视频，但现有小...
近日，一位用户在Linux社区分享了antigravity ...
Chrome扩展Gemini Nexus v3.0是一款强大...
本文探讨了在使用鸭佬中转服务时，如何将Claude Code...
PentAGI 把长任务拆成三层嵌套循环，用每轮落库实现断点续跑、用动态重排替代静态计划，这套骨架可以直接搬到任何要连续跑几小时的 Agent 系统里。它不是靠一个更聪明的提示词把模型哄住，而是假设模型一定会犯错、进程一定会重启、上下文一定会超窗，然后为每一种失败都准备了明确的退路。读它的源码，比读任何一篇 Agent 框架介绍都更能看清「编排」两个字到底要写多少代码。
口径：源码为 vxcontrol/pentagi 的 commit cffed94（2026-10-23），模板行数按文件逐行统计；循环阈值取自 providers/performer.go 常量区。本文只做静态源码分析，未重启服务做运行时验证。
一个渗透测试任务可能连续跑几小时，中间要调用几十次终端命令、网页抓取和外部搜索。把这件事交给大模型，最先崩掉的不是推理能力，而是工程假设：进程会重启、模型会只回一段话而不调工具、消息链会超出上下文窗口、用户会在跑到一半时插一句新要求。用内存里的一个 for 循环扛这些，等于把状态全押在进程活着这件事上。
PentAGI 的解法是把状态全部外置。每轮模型回复、每个工具结果都写回 PostgreSQL 的消息链表，进程启动时先扫描未完成的任务继续跑；出错不判死，统一回到等待人接手的状态；模型输出格式不规范时，有专门的反思角色把它拽回结构化工具调用。三个决策都不新鲜，但放在同一套代码里互相咬合，才是值得拆的地方。
代价也很直接：规划、重规划、反思、纠错、摘要都要额外调模型。它用确定的调用成本换不中断，这个取舍适合长任务，不适合短问答。
| 指标 | 数值 | 说明 |
|---|---|---|
| 提示词模板 | 39 个 | 源码目录 prompts 下的模板文件数 |
| 提示词总行数 | 4419 行 | 按文件逐行统计，非字符数 |
| 主类 agent 轮数上限 | 100 轮 | 调度者、助手与三类执行角色 |
| 其余专家轮数上限 | 20 轮 | 搜索、记忆、顾问等辅助角色 |
| 收尾预留轮数 | 3 轮 | 最后三轮不再调模型，转为写结论 |
最外层是会话循环，一个任务流一个常驻协程，从输入通道收用户的话。它负责状态机、停止、报告和容器资源，启动时先把上次没跑完的子任务续起来。这一层决定了人什么时候能插话，以及插话之后是接着当前任务跑还是新建一个任务。
中间层是任务循环。用户每说一句话就产生一个任务，模型先把目标拆成一串子任务，之后每跑完一个子任务，再让模型根据已完成结果重排剩下的步骤——先把未开始的子任务删掉再重建。这不是静态 DAG，是带条件边的动态计划。
最内层才是通常说的 agentloop，位于 providers/performer.go：一个无限 for，每轮问一次模型、执行它给出的工具、把结果回填，再进入下一轮。三层各自管一件事，谁都不越界，这是整套代码最好读的地方。
| 层 | 代码位置 | 循环内容 | 退出条件 |
|---|---|---|---|
| 外层会话 | controller/flow.go:1288 | 常驻收输入，先续跑未完成任务 | 上下文取消或用户停止 |
| 中层任务 | controller/task.go:341 | 取子任务、执行、重排剩余计划 | 队列清空后写报告 |
| 内层回合 | providers/performer.go:58 | 问模型、执行工具、回填结果 | 终止工具、等待输入或撞上限 |
三层分别对应「人何时插话」「计划怎么改」「这一轮做什么」。
背景：容易看漏的一点：coder、pentester、advice、memorist、search 这些不是外部系统工具，而是「派给另一个 agent」的调用。调度者用一次工具调用把活分出去，专家各自跑一条独立消息链，结果当成工具响应回填。所谓多 agent 是这么实现的，不是同一个大模型换几顶帽子。
单轮顺序很规整：轮首按窗口压缩消息链；带重试调用模型，最多三次、间隔五秒；如果模型没给出任何工具调用，交给反思角色纠偏；把模型消息追加进链并写库；逐个执行工具；把工具结果作为工具消息追加并再次写库；命中终止工具就跳出；轮尾再做一次链压缩，失败只记告警不中断。
护栏挂在三处。第一处是重复检测：连续重复调用同一工具先软提示，超过阈值直接中止链，避免模型在错误上来回打转。第二处是参数修复：工具执行失败时按 JSON 结构让模型改参数再试，但如果是任务状态不允许这类非参数错误，立刻把错误交回模型，不白烧重试次数。第三处是执行导师：调用次数到阈值时请另一个模型复查进度，把建议拼回本次工具响应。
退出条件只有四条：调到终止工具、调到向人提问的工具、撞上轮数上限、或者出错。出错统一回到等待状态，代码注释里写得很直白：即便发生错误，也要把任务流设为等待新输入。这也解释了界面上偶尔看到任务停住不动——多数时候不是卡死，是在等人。
| 约束 | 取值 | 代码出处 |
|---|---|---|
| 主类角色轮数上限 | 100 | performAgentChain 上限分支 |
| 辅助角色轮数上限 | 20 | 同一分支的默认值 |
| 收尾预留 | 最后 3 轮 | 接近上限时改走反思收尾 |
| 模型调用重试 | 3 次 / 5 秒 | callWithRetries |
| 工具执行重试 | 3 次 | execToolCall |
| 连续重复软提示次数 | 4 次后中止 | 重复检测器 |
数值全部来自源码常量，运维可用环境变量覆盖两个轮数上限。
注意：硬上限不是简单报错退出。最后三轮不再调用模型，而是塞一条「快到迭代上限了」的消息，让反思角色把已有结论收住。长任务被迫截断时还能留下可读结果，这个细节比多给几十轮预算更实用。
提示词不是一份大文件。源码把 39 个模板放在同一个目录，合计 4419 行，通过编译期嵌入塞进二进制，每个模板声明自己允许使用哪些变量，渲染前按白名单校验。按用途看，执行专家类占掉接近一半篇幅，说明这套系统把力气花在「每个专家该怎么干活」，而不是把总调度提示词写得越来越长。
运行时用模板引擎把工具名、用户语言、执行上下文、容器内工作目录、镜像名、当前时间和用户文件清单注入模板，渲染结果作为消息链开头落库。网页设置页存的自定义内容会从数据库覆盖默认值；覆盖前重新校验变量，空值或校验不过一律回落默认，注释里点名是为了防止模板把缺失变量渲染成一个不存在的工具名。
执行专家类模板独占 2022 行，接近总量一半；调度者自身只有 678 行。
渗透执行、交互助手、代码开发三个角色的单份提示词都超过 300 行。
| 类别 | 模板数 | 行数 |
|---|---|---|
| 调度与交互 | 2 | 678 |
| 执行专家 | 7 | 2022 |
| 规划与重排 | 6 | 623 |
| 收尾与纠偏 | 7 | 452 |
| 上下文处理 | 4 | 270 |
| 辅助决策 | 6 | 230 |
| 专家提问模板 | 7 | 144 |
合计 39 个模板、4419 行，按文件逐行统计。
第一个是双通道语言。总调度模板明确规定：工具调用里的备注字段用用户语言写，而派发给专家的问题字段一律用英文，专家回传的详细结果也按英文处理；收尾时再把英文结论翻回用户语言，但 CVE 编号、IP、端口、路径和工具名保持原样。这样既让界面上的过程记录能读，又避免多轮翻译把技术标识改坏。中文提问能拿到中文报告、专家之间仍用英文协作，靠的就是这条规则，而不是模型自觉。
第二个是把授权边界写进几乎每个角色模板的开头。模板用一段结构化声明写明这是已获书面授权的测试环境、所有派发任务都已预先授权、不需要再向人确认，并要求不要生成征求许可的步骤。这是合规声明，也是流程保险：否则模型很容易在每一步都追问一句「你有授权吗」，把自动化堵死。
要点：把「什么话用哪种语言」「哪些标识不许翻译」「授权前提是什么」写成模板里的硬规则，比在运行时靠提示词拼接可靠得多。任何需要多角色协作的 Agent 系统都能直接借用这两条。
| 选择 | 换来什么 | 付出什么 |
|---|---|---|
| 每轮两次写库 | 可续跑、可审计、可回放 | 长任务数据库写入压力大 |
| 三层循环加动态重排 | 能被中途打断，计划随结果调整 | 规划与纠错都是额外模型调用 |
| 出错统一回等待 | 一次模型抖动不会判死任务 | 界面看着像卡住，需要解释 |
| 100 / 20 轮硬上限 | 防止无限打转 | 复杂任务可能被提前收尾 |
| 提示词编译进二进制 | 部署不依赖外部文件 | 改默认模板必须重新构建镜像 |
真正能搬走的不是某个函数，是三条边界：状态外置到数据库而不是留在内存；把模型输出当成不可信输入，为格式错误、参数错误、重复调用各准备一条退路；把计划做成可重排的队列，而不是一次性生成后不再改。这三条在你做过的调度系统、容器编排和机器人任务管理里都能找到对应物，只是这里把它们收进了同一个进程。
要警惕的是成本结构。反思、纠错、导师、重排、摘要都是独立模型调用，用便宜模型跑长任务时，这些「保险」的调用次数可能比真正干活的工具调用还多。源码里用轮数上限和角色分级来控制它，但上线前仍应按自己的单价重新算一遍。
下面这份速查按阅读顺序列，从外层一路走到内层，再跳到提示词装配。文件路径相对仓库 backend/pkg 目录，行号对应 commit cffed94。
controller/flow.go:1288 外层会话循环
controller/flow.go:1353 用户输入转为任务
controller/task.go:341 中层子任务队列循环
controller/subtasks.go:70 首次拆分计划
controller/subtasks.go:106 每步重排剩余计划
controller/subtask.go:294 中内层接缝
providers/provider.go:708 进入 agent 链
providers/provider.go:672 系统提示词渲染
providers/performer.go:58 内层循环主体
providers/performer.go:282 单工具执行与护栏
templates/templates.go:20 模板编译期嵌入
templates/templates.go:522 默认提示词组装
controller/prompter.go:37 自定义覆盖与校验
tools/registry.go:12 工具常量与分类
csum/chain_summary.go:98 消息链压缩
开发者近日在 V2EX 发布了一款名为 v2term 的开源终端客户端，可将 V2EX 论坛的浏览体验完整搬进命令行界面。由于终端中滚动的文本远看与 Codex、Claude Code 等 AI 编程工具的对话界面高度相似，该项目被定位为一种更具隐蔽性的“摸鱼”方式。功能方面，v2term 支持鼠标点击与滚轮翻页，图片默认折叠、可按需展开查看；还能将相互关联的回复自动串成对话链，并支持热评置顶，方便快速掌握帖子脉络。公开帖子无需登录即可浏览；若需回复或感谢，用户可导入浏览器中的 V2EX Cookie 完成身份认证。安装方面，使用 Homebrew 的用户可通过 brew install synrise25/tap/v2term 一行命令完成部署，随后运行 v2term 即可启动。项目以 MIT 协议开源，源码托管在 GitHub 仓库 synrise25/v2term。作者同时征求社区反馈，建议用户报错时附带操作系统与终端名称，并幽默提示隐蔽性效果需自行实测，被发现的后果自负。从技术形态看，该项目属于典型的 TUI（终端用户界面）应用实践，展示了终端生态在信息流阅读场景下的可塑性，也为开发者社区的第三方客户端提供了一个新样本。
核心观点：AI 编程工具的高频存在正在重塑终端界面的语义，同一块黑屏，既能用于工作，也能成为摸鱼的完美掩体。
原文链接：V2EX 分享发现
Claude Desktop的MCP工具占用token过高的问题近期在开发者社区引发讨论。一位Linux.do论坛用户发帖称，其长期使用Anthropic官方Pro订阅及Claude Code，在未开启对话的情况下，上下文占用通常维持在约70K token的水平。近期该用户在Windows 11系统上尝试Claude Desktop时，发现初始上下文消耗异常巨大，随即在社区发帖求助。
据该用户描述，其已关闭artifacts功能，且从未安装任何connector，但初始上下文占用依然高企，因此质疑MCP tools正是token消耗的主要来源。帖子中还提到，用户听闻过tool search相关功能，猜测该机制或许与上下文占用问题存在关联，希望社区提供解决思路。
从技术背景看，MCP（Model Context Protocol）是Anthropic推出的模型上下文协议，用于让大模型接入外部工具与数据源。在现有实现中，每个MCP server提供的工具名称、功能描述及参数Schema通常会被整体注入系统提示词，随着接入工具数量增多，这部分静态开销会显著挤占可用于对话的上下文窗口。70K级别的初始占用意味着用户每次对话的可用空间与隐性成本都受到明显影响。
tool search则是业界正在探索的动态工具检索方案，即让模型按需搜索并加载工具定义，而非在会话开始时预载全部工具，被视为缓解该问题的潜在路径之一。目前该帖尚处于讨论初期，社区尚未给出明确的量化结论与通用解决方案。
从技术演进看，缓解路径主要有三条：一是tool search等动态工具检索机制，让模型按需加载工具定义；二是协议层面的描述精简与分层注入；三是客户端智能筛选，仅挂载当前任务真正需要的server。若Anthropic在Desktop或Claude Code中内置类似机制，或将改变MCP工具的组织与分发方式。
更宏观地看，上下文管理能力正成为Agent基础设施的核心竞争力，工具生态的丰富度与上下文效率之间的平衡，将直接影响各家Agent产品在复杂任务中的实际可用性与运行成本。
核心观点：MCP生态越繁荣，上下文开销越沉重，工具动态检索能力将成为Agent产品竞争的分水岭。
原文链接：Linux.do
据 Linux.do 论坛用户发帖披露，其在使用 Claude Code 及网页版 Claude 期间，因切换不同的美国 IP 地址，Claude 门户突然弹出 KYC（Know Your Customer）身份验证要求。该用户表示手上没有 BNO 护照（英国国民海外护照），最终使用香港身份证完成了这次验证，并表示将观察“香港身份 + 美国 IP”组合的后续使用情况。这一实测案例表明，Anthropic 正在部分场景下对 Claude 服务启用强制性身份验证，触发条件疑似与 IP 地址变动、访问模式异常等因素相关。此前 Anthropic 已宣布将面向部分用户群体推行 KYC 验证，此次帖子是该政策落地到个人使用者的直接反馈。对于依赖非常规网络环境访问 Claude 的用户而言，KYC 的出现意味着账号与真实身份的绑定进一步收紧，账号共享、批量注册等灰色使用方式的门槛显著提高。该帖子已引发社区对 Claude 身份验证的覆盖范围、认可材料类型以及后续风控走向的讨论，是观察头部 AI 厂商账户治理策略变化的真实样本。
核心观点：AI 服务进入强实名时代，身份验证正成为新的访问门槛，依赖灰色通道的使用空间正在加速收缩。
原文链接：Linux.do
微软云服务状态页显示，Microsoft 365多项服务出现大范围连接故障，事件编号MO1550821，受影响服务包括Exchange Online、Teams、SharePoint Online、Microsoft Copilot、Defender XDR、Planner、To Do以及Purview的多项子服务，当前状态为服务降级。微软初步调查显示，故障可能源于受影响服务器上一个负责处理健康检查的特定组件失效，导致大量服务器意外下线，剩余基础设施负载激增，进而引发多区域连接错误，且服务器在处理请求时出现处理器使用率异常升高。微软在近期变更审查中还发现少量配置更新可能是潜在诱因。恢复方面，微软已暂停所有部署与配置变更，先在部分服务器上部署针对性变更以绕过故障组件，验证有效后正扩大应用范围；同时准备自动化恢复流程，持续检测并重启无响应服务器；并已完成全球范围内连接流量重新分配，将更多流量转移至其他基础设施，页面标题“我们正在重新路由协议”即指向这项工作。Hacker News社区讨论中，有用户批评状态页面需登录才能查看，认为认证服务故障时将无法获知状态；另有用户指出存在无需登录的公开版本。还有用户报告无法登录账号、2FA验证码邮件未送达、Outlook返回错误语言提示等问题，另有评论猜测“负载增加”的表述可能指向DDoS攻击，登录重定向客观上起到了流量分流作用。
核心观点：健康检查反成故障源头，Copilot与传统服务共享同一故障域，AI应用的可靠性仍被底层云基础设施的短板所钳制。
原文链接：Hacker News
一位Linux用户在V2EX分享了自己更换输入法的经历，并推荐了一款名为WowType的开源输入法项目。据其介绍，他早年一直使用搜狗输入法，但搜狗官方Linux版在Ubuntu 22.04之后的系统版本上不再兼容，迫使其寻找替代方案。随后他转向Rime配合雾凇拼音的组合方案，但实际使用中发现Rime配置流程复杂繁琐，且拼音输入体验不够理想。近期试用后，作者发现了WowType这款新输入法，其突出特点包括：通过脚本即可一键安装，大幅降低部署门槛；输入响应速度快；并支持离线语音输入功能，无需联网即可完成语音转文字。该项目已在GitHub上开源，作者将其推荐给使用Linux系统的用户。Linux桌面端的中文输入法长期以来是生态短板，搜狗、百度等主流商业输入法的Linux版本更新停滞，大量用户流向Rime、Fcitx5等开源方案，而Rime的高度可定制性也带来了配置复杂的问题。WowType主打开箱即用与离线语音能力的组合，试图在易用性与功能丰富度之间寻找平衡。对于依赖Linux桌面办公的开发者和重度用户而言，输入法体验直接影响日常效率，此类开源项目的出现为该细分领域提供了新选择。项目目前处于早期阶段，实际稳定性和词库质量仍有待更多用户验证。
核心观点：商业软件撤离Linux后，开源社区正以一键安装加本地AI能力填补空白，传统工具的竞争逻辑已被改写。
原文链接：V2EX 分享发现