【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载导读audit-performance是 jevgrep 仓库内置的 Agent 技能之一它定义了一套可执行的性能审计流程先找到没有有用边界地增长、或重复却毫无进展的工作产出证据支持的台账或报告再选择能保留恢复能力的最小修复。本文以该技能文档.agents/skills/audit-performance/SKILL.md为骨架结合 jevgrep 检索管线packages/core/src/retrieve.ts、packages/core/src/evaluator.ts、packages/core/src/cache.ts、packages/core/src/filesystem.ts的真实实现讲解六步工作流、优先级策略、护栏与完成定义并给出有界工作 持续恢复在真实代码中的落地形态。读完本文你将掌握一套可直接用于任何代码库的性能审计 SOP以及验证修复确实有界且仍可恢复的红/绿证明方法。一、这个技能要解决什么问题技能开篇就给出了核心判断标准Find work that grows without a useful bound or repeats without progress.即审计的目标不是发现慢的代码而是找到两类病态工作无界增长grows without a useful bound工作量随历史、租户、路径数或故障时长线性/超线性增长却没有与之匹配的上限无进展重复repeats without progress轮询、重试、批次扫描在没有任何状态必须改变的情况下反复执行可能永远循环或饿死。同时要求产出evidence-backed ledger or report有证据支撑的台账或报告并prefer the smallest fix that preserves recovery优先选择保留恢复能力的最小修复。这两点分别对应技能末尾的 Guardrails 与 Done 定义是整份文档的方法论闭环。二、六步工作流从热路径追踪到红/绿证明第一步Trace hot paths追踪热路径Find recurring syncs, polls, streams, retries, queues, scheduled jobs, filesystem walks, and request-time reads. Follow each through its production caller; ignore test-only paths.需要关注的工作形态包括周期性同步、轮询、流、重试、队列、定时任务、文件系统遍历、请求时读取。关键纪律是Follow each through its production caller——必须沿生产调用链追踪忽略测试专用路径。以 jevgrep 为例检索管线中的热路径清晰可循文件系统遍历discover()从根目录逐层列出目录与文件见 packages/core/src/retrieve.ts请求时读取每个候选文件经unchanged()重新读取并比对内容哈希后才允许上传见 packages/core/src/retrieve.ts重试/队列导航打分失败的批次被二分拆分后重新追加到同一队列见 packages/core/src/retrieve.ts。第二步Compute the amplification计算放大倍数State the trigger and worst-case work in concrete units: rows, queries, pages, entries, bytes, jobs, retries, or full-file rewrites. Distinguish a bounded large constant from work that grows with history, tenants, paths, or outage duration.放大倍数必须用具体单位描述行、查询、页、条目、字节、任务、重试次数或整文件重写。更重要的是区分两种性质完全不同的工作量有界大常量bounded large constant最坏情况固定可以接受随历史/租户/路径数/故障时长增长的工作真正的风险。jevgrep 中的放大计算有明确数字可查边界默认值位置遍历条目总数100_000超出即记录resource_limitretrieve.ts导航请求批大小128 项 或 38_000 字节二者先到先拆retrieve.ts目录预览64 条目 或 4_096 字节后截断retrieve.ts单文件读取上限16 MiBmaxFileBytesfilesystem.ts单源文件上传上限1_000_000 字节超出记录resource_limit/source_inspection_limitretrieve.ts忽略规则文件上限1 MiBmaxIgnoreBytesfilesystem.ts这些数字把最坏情况工作量固定成了常量而不是随仓库规模无限放大——这正是第二步要求区分有界大常量与随路径数增长的工作的实践。第三步Check forward progress检查前向进展For every retry, fixed-prefix batch, cutoff, or transitional poll, identify what changes before the next attempt. If nothing must change, it can loop or starve forever. Check that partial fixes do not merely delay the same work.对每一个重试、固定前缀批次、截断或过渡性轮询都必须回答下一次尝试前什么必须发生变化如果什么都不必改变它就可能永远循环或饿死。同时要警惕部分修复不能只是把同样的工作推迟到以后。jevgrep 的源码处处体现这个原则批打分失败后的二分拆分一组导航项打分失败时代码把组从中间拆成两半重新入队而不是整组无限重试。只有当叶子组仍失败或发生终端失败时才记录 issue——恢复成功的父组不算不完整A recovered parent is not incomplete见 retrieve.ts。这就是重试前有状态必须改变组变小的典型实现。目录遍历的游标分页listPage()返回nextCursor消费完一页才继续下一页见 filesystem.ts。即使中途放弃closeCursor也不会重新从头扫描同一前缀。429 冷却是有进展的等待遇到 429 时解析retry-after头把cooldownUntil向后推等待期间可被取消信号中断见 evaluator.ts。等待本身不产生新请求但时间推进使得下一次尝试有实际意义。内容哈希保鲜校验任何一次上传前都通过unchanged()复核源文件哈希源已变化则丢弃缓存证据防止把过期源传给模型后拿回无效结论。第四步Falsify severity证伪严重性Inspect existing caps, indexes, backoff, deadlines, healing owners, and caller frequency. Dismiss findings already bounded cheaply enough or continuously healing.找到疑似问题后先检查已有的上限、索引、退避、截止时间、自愈 owner 和调用频率——已经足够便宜地被限制住或在持续自愈的发现应当直接驳回而不是强行修复。jevgrep 中有大量这类已证伪的机制并发与请求上限stageWorkers 32限制每个阶段并发retrieve.tscreateEvaluator默认并发 32、请求总数上限 50_000evaluator.ts、evaluator.ts超时截止每次模型调用包裹AbortSignal.timeout(options.timeoutMs ?? 15_000)默认 15 秒evaluator.ts认证失败全局自愈401/403 触发独立的authenticationFailureAbortController一次性中止所有等待中的请求避免逐请求空转evaluator.ts、evaluator.ts调用频率CLI 提供--concurrency帮助文档明确建议慢网络下用 1–4apps/cli/src/args.ts。如果一个发现对应的路径已经具备上述任一机制且成本足够低就应记录驳回理由而不是进入修复队列——这能显著压缩性能台账中的噪音。第五步Record before fixing先记录再修复If the project keeps a performance ledger, append every supported finding and important dismissal using its existing convention. Otherwise return a compact report. Include priority, trigger, impact, current owner, acceptance seam, and evidence.无论项目是否有正式的性能台账纪律都是一样的动手修复之前先把发现落成记录。记录必须包含六个要素priority优先级依据下文策略trigger生产触发条件impact影响current owner当前 owneracceptance seam验收接缝在哪个最外层接缝上证明红/绿evidence证据第六步用策略排序并完成红/绿证明If implementation is authorized, invoke the projects test-writing workflow and prove the old behavior red at the outermost practical seam. Fix, review, and update the ledger or report with verification evidence.实施被授权后调用项目的测试编写流程在最外层可行的接缝处把旧行为证明为红然后修复、评审最后用验证证据更新台账或报告。这里的红/绿证明不是普通的单元测试而是要在 Done 节中强调的双重证明修复后既要有界bounded work又要持续恢复continued recovery。三、优先级策略什么该修什么不该修最高优先级会造成可见损害或毒项技能文档给出的最高优先级条件是问题可能造成用户可见的冻结或错误user-visible freeze or error内存/磁盘增长memory/disk growth请求处理被阻塞blocked request processing数据丢失data loss舰队级放大fleet-wide amplification毒项poison item一个坏数据/坏任务堵塞在队列头阻止后续所有工作低风险修复偏好Prefer low-risk fixes that bound existing work: stream pagewise, honor backpressure, coalesce schedules, move poison rows aside, skip proven no-ops, or make one exhaustive search end in a terminal verdict.偏好给已有工作加上界的低风险修复具体手法包括stream pagewise按页流式处理——对应 jevgrep 的游标分页honor backpressure尊重背压——对应stageWorkers有界并发与acquire()等待队列evaluator.tscoalesce schedules合并调度move poison rows aside把毒行挪到一边skip proven no-ops跳过已被证明的无效操作——对应缓存命中直接返回evaluator.tsmake one exhaustive search end in a terminal verdict让一次穷尽搜索以终局裁决收尾。safety cap 的定位A safety cap is a pathology guard, not a normal product limit: set it above legitimate large workloads, emit actionable telemetry when reached, and define what happens next.安全上限是病理守卫不是正常产品限额要设在合法大工作量之上达到时发出可操作的遥测并定义接下来发生什么。jevgrep 对此的执行非常典型——100_000条目上限达到时记录resource_limitissue最终结果状态变为incompleteCLI 退出码 2而不是静默返回残缺结果retrieve.ts、apps/cli/src/index.ts。不要按吓人的计数排序技能文档明确警告三条看起来吓人但不必修的情况轮询可以无限继续只要被轮询的状态有真实的恢复 owner、最终可能变化就修永远不会愈合的状态而不是修只是活得很久的计时器廉价的有界数据库工作没有生产证据就不要为了减少一个适度的固定查询数去建投影、缓存、游标状态机或替代读模型不要优化掉即将有用的信息如果数据可能很快支撑产品 UI 或行为就不要提前裁剪。这三条本质上是在对抗看到 count 就动手的本能与第四步的证伪严重性互为表里。四、护栏Guardrails修复不得破坏恢复能力技能文档给出六条护栏每一条都能在 jevgrep 源码中找到对应实现或对应测试。护栏 1保留 healingPreserve healingA cache or no-op shortcut must retain cheap recovery signals and fall back to ordinary reconciliation on drift, uncertainty, restart, or prior failure.缓存或no-op 捷径必须保留廉价的恢复信号并在漂移、不确定、重启或先前失败时回退到普通对账。jevgrep 的缓存设计完全符合缓存条目以sha256(JSON.stringify([schema, namespace, request]))为键只存答案不存请求原文每次读取校验 schema、时间戳、答案类型与 TTL默认 7 天任何不符都按未命中处理packages/core/src/cache.ts。更重要的是缓存命中前仍会执行policy.beforeAttempt的源哈希复核evaluator.ts即命中缓存也要确认源没变——这就是保留廉价恢复信号、漂移时回退对账的字面实现。测试 test/retrieval-freshness.test.ts 专门验证排队的导航请求永不把随后被排除的源上传出去。护栏 2恢复扫描必须完成或持久化进展A recovery scan must either finish or persist forward progress. For a local, prunable namespace, prefer one complete pass with a ceiling high enough to indicate pathology rather than an ordinary large project. For a legitimately huge namespace, persist a cursor and resume after it.恢复扫描要么完成要么持久化前向进展对本地可修剪的命名空间倾向一次完整扫描上限设到足以标示病理而不是普通大项目的量级对真正巨大的命名空间持久化游标并在其后恢复找到目标即更新身份穷尽未命中或异常上限产生该领域的终局裁决绝不要永远重启同一个部分前缀。jevgrep 的listPage游标就是持久化前向进展的实现——每次调用返回nextCursor调用方决定继续、暂停或closeCursor主动放弃filesystem.ts从结构上杜绝同一前缀从头重扫。护栏 3分离可重试失败与终局失败Separate retryable failures from terminal ones. A permanent rejection must not sit at a queue head or fixed prefix forever.可重试失败与终局失败必须分离永久拒绝绝不能一直堵在队列头或固定前缀。jevgrep 的evaluator是教科书级实现401/403 → 立即触发全局认证中止不可重试evaluator.ts408/429/5xx/TimeoutError/可重试网络错误 → 判定为 transient才允许重试evaluator.ts导航类多问题请求默认只尝试 1 次attemptLimit navigation multiple ? 1 : 2429 时才放宽到 2 次evaluator.ts、evaluator.ts。护栏 4双向绑定传输与队列Bound both sides of a transport and every durable/in-memory queue. State the overflow behavior; never silently drop accepted durable data.传输的两端和每个持久/内存队列都要有界必须说明溢出行为绝不静默丢弃已接受的持久数据。jevgrep 的双向绑定非常具体上行请求有38_000字节批上限与request-sizeissue下行答案单条maxEntryBytesmin(maxBytes, 1 MiB)超限即cache_limitcache.ts、cache.ts内存中排队请求在认证失败/取消时被显式 reject 而非悬挂evaluator.ts。溢出行为都以 issue 形式记录在结果中最终可见于 CLI 的incomplete状态。护栏 5匹配产品生命周期Match compatibility work to the product lifecycle. In prelaunch code, prefer direct changes and add no legacy branches or migrations unless real persisted data requires them.兼容性工作要匹配产品生命周期prelaunch 代码中偏好直接修改除非真实持久数据需要否则不添加遗留分支或迁移。这一点在 jevgrep 中体现为缓存 schema 的版本化设计缓存键和载荷都携带schema当前为 1与policyVersion、parserVersion、promptVersion、protocol等命名空间字段cache.ts、evaluator.ts——语义变化时旧条目自然失效而不是为旧格式写兼容分支。护栏 6每个限制必须有可观测信号Every limit introduced or changed must have an observable log or metric with the limit kind, configured bound, affected owner, and overload outcome.每个引入或改动的限制都必须有可观测的日志或指标包含限制类型、配置的边界、受影响的 owner、过载结果。jevgrep 的 issue 机制就是统一的可观测出口issue(kind, count, message)把resource_limit、request-limit、cache_corrupt、cache_unavailable、cache_limit、source-invalid、changed、interrupted、authentication等全部聚合进result.issues并附带命中/未命中统计retrieve.ts、cache.ts。CLI 层把这些转成退出码0 完成、1 失败、2 不完整、130 中断apps/cli/src/args.ts、apps/cli/src/index.ts下游 Agent 可以据此判断缺了哪些上下文。五、完成定义Done什么才算真正做完技能文档用两句话定义完成缺一不可The audit is complete only when every finding has a production trigger, quantified amplification, priority rationale, acceptance seam, and recorded disposition; every dismissed candidate says which bound or healing mechanism makes it acceptable.审计完成的标准每个发现都有——生产触发、量化放大、优先级理由、验收接缝、已记录处置每个被驳回的候选都必须说明是哪个边界或愈合机制使它可接受。也就是说驳回不是简单忽略而是要给出一条可追溯的理由。An implementation is complete only when its red/green proof shows bounded workandcontinued recovery.实施完成的标准红/绿证明必须同时展示有界工作与持续恢复。这解释了为什么 jevgrep 的每次修复都要带上像unchanged()哈希复核、429 冷却、游标续扫这样的恢复机制——只证明工作量变小了是不够的还必须证明系统在异常后仍能自己站起来。六、把方法论落进真实仓库jevgrep 检索管线复盘如果你要在自己的仓库执行这套审计jevgrep 本身就是一份标准答案式的样例。把六步工作流套在它的检索管线上Trace从retrieve()入口packages/core/src/retrieve.ts沿discover → score → select → assessFiles → selectTestBodies走一遍生产调用链Amplification把遍历条目100_000、导航批128/38_000 字节、源大小1 MiB、文件读取16 MiB换算成最坏情况字节与请求数确认全部是有界常量Forward progress核对每个重试批二分、429 冷却、哈希复核都有下次尝试前必须改变的变量Falsify把已经被stageWorkers32、requestLimit50_000、timeoutMs15_000、认证中止、缓存 TTL 覆盖的发现直接驳回并记录理由Record所有未被驳回的发现进入台账标注 priority/trigger/impact/owner/acceptance seam/evidencePrioritize prove对最高优先级项在最外层接缝写红/绿测试——仓库的 test/retrieval-freshness.test.ts 与 test/evaluator.test.ts 就是这样验证源变更后缓存与摘要被正确失效的。结语audit-performance的完整方法论可以浓缩为一句话找到无界增长或无进展重复的工作量化它证伪它记录它然后用保留恢复能力的最小修复收口它。技能文档给出的六步工作流负责发现问题优先级策略负责决定修什么六条护栏负责确保修复不引入新病理Done 定义负责验收到底做没做完。当你在自己的代码库里追踪轮询、重试、队列与扫描时不妨逐条对照 jevgrep 的实现——每一个看起来的边界背后都应当同时站着上限数字和自愈机制这两样东西。赞分享【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载相关推荐cloudflare-security-audit 技能实战AI/LLM/Agent 攻击面安全审计方法论cloudflare security audit 技能实战AI/LLM/Agent 攻击面安全审计方法论 导读 本文以 AAS 仓库中 cloudflareAI 技能AI 插件OpenFang security-audit 技能详解基于 OWASP 与 STRIDE 的 Agent 安全审计方法论OpenFang security audit 技能详解基于 OWASP 与 STRIDE 的 Agent 安全审计方法论 导读 security audit人工智能大模型AI Agent自主智能体Agent 编排MCP Clients知识图谱GitLens a11y-audit 技能全解基于 WCAG 2.1 AA 的代码可访问性静态审计方法论GitLens a11y audit 技能全解基于 WCAG 2.1 AA 的代码可访问性静态审计方法论 导读 GitLensvscode gitlens开发工具版本控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考