今天的信号集中在“AI 从会生成，转向可落地、可审计、可控边界”：一边是文档解析、浏览器操控、设计规范和 OCR 这类能马上装起来的基础工具继续下沉；另一边，代码 Agent 的项目指令开始走向跨工具标准化，但 ZCode 全仓快照争议和军事情报误判又同时提醒大家，权限边界、数据出站与人工复核不能被“Agent 自动化”掩盖。证据增强脚本本次运行超过 300 秒未产出证据包，以下可上手条目仅纳入已用官方仓库、官方模型页、项目 README 或可信网页交叉核验的内容；🌱栏目保留原文线索并标注证据状态。
腾讯开源的页面图像文档解析模型，把一页文档直接转换为结构化 Markdown，并处理 LaTeX 公式、HTML 表格和阅读顺序。
先克隆仓库并准备 Python 3.10+ 环境，按 README 安装 vLLM 依赖；显存允许时先用 2B 检查链路，运行 `bash scripts/serve_vllm.sh Tencent/WeVisDoc-2B` 启动 OpenAI 兼容服务，再用 `bash scripts/run_demo.sh` 处理仓库自带图片。自己的 PDF 先逐页渲染成 PNG/JPEG/WebP，再调用 `python -m wevisdoc.client --image page.png --output results/page.md`；如果要批处理，可使用 `--image-dir`、`--result-dir` 和 `--workers`。4B 版本应先核对 GPU 显存与 vLLM 配置，不要直接把整本扫描 PDF 一次性塞进上下文。
它不是把 OCR、版面分析、公式识别、表格抽取拆成多个容易错位的流水线，而是端到端输出统一结构。官方 README 给出了 OmniDocBench v1.6 与 PureDocBench 的对比结果，2B/4B 都列在前列；同时保留本地 Transformers 和 vLLM 两种部署路径，适合把扫描资料、合同、题库或研究 PDF 接入自己的知识库，而不是只做一次网页演示。
一个 MCP server 加 Chrome 扩展，让 Claude Code、Codex CLI、Cursor、Gemini CLI 等 Agent 操作你正在使用的 Chrome 登录态。
在一台专门用于自动化的 Chrome 上先安装扩展，然后运行 `npx huashu-chrome install`；它会检测本机 Agent 配置并写入 MCP 配置，动手前可先加 `--dry-run` 查看变更。安装后运行 `npx huashu-chrome doctor`，确认本地桥接和扩展握手正常，再在 Claude Code 或 Codex 中调用 MCP。第一次使用建议只打开一个低风险测试站点，先做读取、截图、表单草稿等操作；涉及发帖、下单、付款、验证码或扫码时必须让 Agent 停下来交还人工，不要把真实登录态当成无风险 API。
它解决的是浏览器 Agent 最实际的一层断点：接口能调用，不等于能带着已有登录态完成真实网页操作。README 明确描述了 npm 包、CLI、MCP、本地桥和扩展的组合，并强调用页面真实状态验证动作是否发生；同时有会话隔离、人工交接和权限边界设计。对后台录入、跨站搬运、已登录 CRM 或内容平台操作很有价值，但也意味着扩展权限和工作区隔离必须纳入安全评审。
一个开源的设计工程概念集，把光学对齐、嵌套圆角、等宽数字、克制 hover 等“完成感”细节整理成可执行规则和示例。
先打开在线站点按章节浏览，挑出项目真正需要的视觉规则；如果要让 Coding Agent 使用，可克隆仓库，把相关概念、推荐值和代码示例整理到项目的 AGENTS.md、CLAUDE.md 或专用 skill 中，再要求 Agent 在写组件前先引用对应规则。实际操作时不要一次性把整套规范塞进每个提示词，可以按页面类型选择布局、类型、颜色、动效或组件章节，并让 Agent 先生成一个小页面，再用浏览器截图和人工 checklist 检查对齐、层级、状态和动效。
很多 AI 生成的界面“能用但像模板”，问题不在缺少组件，而在细节没有形成可复用的判断标准。Craft 的价值是把审美经验转成可查阅的静态内容和交互 demo，方便接入 Agent 的上下文。它不是设计自动生成器，也不能替代设计评审，但能把“更精致一点”变成更可验证的规则，尤其适合快速原型和内部工具统一视觉语言。
Jina AI 基于 DeepSeek-OCR 路线微调的端到端文档解析模型，社区已提供 vLLM 部署封装，可按 OpenAI 兼容接口调用。
先在官方模型页核对权重、许可和硬件要求，再使用社区封装仓库的 Docker Compose 方案；准备 Hugging Face 访问凭据和 `HF_TOKEN`，设置 `VLLM_PLUGINS=jina_ocr_register` 后运行 `docker compose up --build`，服务默认监听本地 8791。启动后用仓库中的 `scripts/test_table.py` 对表格图片做一次端到端测试。注意该封装 README 明确提示推理时显存可能动态增长，不能只按静态 KV cache 估算；在个人机器上应先降低显存利用率、限制并发，并用脱敏图片验证结果。
文档 OCR 的瓶颈往往不是“认出文字”，而是公式、表格和版面关系能否一次性保留。这个项目的外部证据目前主要是官方模型入口加社区 vLLM 适配器，适合把它视为可验证的部署线索，而不是直接接受推文中的所有速度对比。它更值得关注的地方在于：如果同一模型能进入标准 OpenAI 接口和容器化推理链路，企业就能较低成本把 OCR 模块接入既有文档流水线。
Claude Code 在没有 CLAUDE.md 的目录中可读取 AGENTS.md，并可在 `/config` 的项目指令设置里切换这一行为。
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md ↗
https://github.com/anthropics/claude-code/tree/main/mods/agents-md ↗
先确认本机 Claude Code 版本和项目目录层级，再在仓库根目录或对应子目录创建经过审查的 AGENTS.md，把构建命令、测试入口、目录约束、数据边界和提交规范写清楚；不要直接把旧 CLAUDE.md 原样复制后堆叠冲突规则。升级到包含该变更的版本后运行 `/config` 检查项目指令选项，在一个小型测试仓库里分别验证“存在 CLAUDE.md”和“只有 AGENTS.md”两种路径，确认 Agent 实际读取的规则与团队预期一致。共享规则仍应避免写入密钥、Cookie 或个人路径。
这不是又增加一个模型能力，而是减少多 Agent 协作时的说明文件分叉。官方 CHANGELOG 明确写出 2.1.277 的行为边界：没有 CLAUDE.md 时才读取 AGENTS.md，且部分云端后端当时尚未覆盖；官方仓库还提供 agents-md mod。它让跨 Codex、Claude Code 等工具共享基础工程约束更现实，但也提醒团队必须做规则优先级测试，避免把工具专属指令和通用项目规范混在一起。
一个社区开源的 2048 实验，把 TypeSafe 的 Jev 决策模型接入游戏，每回合只让模型从合法方向中选择下一步。
按仓库 README 准备 Python 3.10+、Node 20+ 和 Jev API key；后端安装依赖并配置 `.env`，启动 FastAPI 后访问本地页面。先用默认状态格式跑多局，再逐项修改棋盘编码、空格数量、单调性、平滑度、可合并方块和最近一步等字段，观察同一个决策模型在不同上下文下的胜率与请求载荷变化。若 API 不可用，项目的本地启发式 fallback 会继续运行；测试结束后记得删除 `.env` 和运行数据，不要提交密钥。
这个 demo 把“Agent 做决策”拆成可观察的状态、选项和结果，而不是只展示一句看起来聪明的回答。仓库同时展示并行运行、可编辑状态格式、请求 JSON 预览、服务端游戏逻辑和 fallback，这种可观测性很适合用来理解决策模型如何受上下文设计影响。它不是通用 Agent 框架，API key 和外部服务仍是门槛，但作为低风险实验场很适合比较状态表示、合法动作约束与模型置信度。
社区逆向分析称 ZCode 曾在登录状态下打包并上传工作区及 `.git` 内容；智谱随后将问题归因于 Repo Wiki/代码仓库索引默认行为，称已修复并承诺开源与接受第三方评估。
目前能确定的不是“数据一定被滥用”，而是一次引发争议的出站路径：研究者给出了快照、加密、对象存储上传和重试等技术线索，媒体又记录了官方对 Repo Wiki 默认设置和修复的回应。两类信息要分开看，社区逆向材料说明“客户端做了什么”，官方回应说明“产品方如何解释和处理”，但数据实际保留多久、受影响用户范围、修复版本和第三方复核结果仍需要后续证据。对任何 Coding Agent，真正的验收不应只看模型质量，还要抓包确认默认上传范围、开关语义、删除承诺和失败重试行为。
这会把“是否允许 Agent 读仓库”升级为“哪些文件能离开机器、以什么密钥加密、谁能解密、什么时候删除”的产品竞争点。企业采购时需要把 `.git`、LFS、缓存、环境变量、未提交文件和日志列成明确测试项；个人开发者在处理商业代码、客户数据和密钥时，也不能把“加密上传”误认为“服务方无法读取”。若官方开源和第三方审计兑现，事件可能推动 Coding Agent 建立更清楚的本地模式与最小上传原则。
多家媒体转述 CNN 报道称，一份借助聊天机器人生成的错误情报把船上货物误判为核项目部件，美军在进一步核查前已准备拦截并登船。
报道目前没有确认所用软件是商业产品还是政府定制系统，也没有确认船只真实货物，因此不能把它写成某个具体模型的事故。但案例的流程风险很清晰：模型把公开信息和机密信号材料混合后产生错误判断，人又把结果整理成格式规范、看起来像传统情报产品的报告并传播，格式的权威感掩盖了不确定性。核心教训不是“高风险领域不能用 AI”，而是每个关键事实必须保留来源、置信度、反证和独立复核记录，不能让模型同时承担推断、包装和发布。
医疗、金融风控、政务和安全场景都会遇到相似的“生成内容进入正式流程”问题。产业上，模型供应商会被要求提供引用、审计日志、权限分层和人工签核接口；使用方则要为“不可自动执行”的动作设置硬闸门。对于 Agent 产品，回答速度和格式完整不再足够，能够回放“输入了什么、模型推断了什么、谁批准了什么、何时发现错误”会成为企业部署的基本能力。
X List 转述 Anthropic 首次公开一组内部指标，试图衡量 Claude 参与自身 AI 研发的程度、安全监督跟进情况和算力使用方向。
这条素材值得关注，但本次没有拿到对应的完整官方原文，具体数字不应当当作已独立核验事实。即使指标本身成立，解读也不能简单等同于“AI 已经自主研发”：研发任务的拆分口径、人工介入比例、代码或实验是否被采纳、评测是否独立，都决定了百分比的含义。它更像一个行业正在形成的测量问题：实验室如何把 Agent 对研究流程的贡献、收益和风险同时量化，而不是只展示一次成功 demo。
如果前沿实验室持续公开这类指标，行业评价可能从模型基准扩展到“模型能否改进数据、代码、评测和安全流程”。这会推动研发组织建立任务级审计、贡献归因和安全监督看板，也会让外界更容易比较不同实验室的自动化深度。反过来，指标若缺少定义和可复现方法，也可能变成新的营销数字，所以后续应重点追踪原始方法、样本范围和人工审核口径。
List 中多条讨论认为，Agent 生成代码后，人类不必逐行审美式检查，而应更多依赖测试、验证和可复现结果；同时也出现了对闭源 Agent、整仓上传和权限安全的强烈反弹。
这不是“代码细节不重要”，而是质量控制的位置发生移动：人类把时间从重复实现转向定义验收条件、设计反例、检查边界和追踪失败证据。若项目没有测试、日志、权限闸门和回滚能力，单纯少看几行代码只会把风险隐藏得更深。今天的素材把两面放在了一起：验证驱动可以提高交付效率，但透明度和数据边界必须同步提高，否则“黑盒验证”容易变成无法追责的黑盒。
Agent 原生工程会更需要任务规格、自动化测试、差异审查、运行时监控和安全扫描的组合，而不只是一个更强的模型。对团队而言，招聘和协作标准也会变化：能写清验收条件、构造失败用例和解释运行证据的人，可能比单纯手写更多代码更关键。对产品方而言，是否能导出完整轨迹、限制工具权限并支持本地化部署，会直接影响企业信任。
