ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AG Kit `/status` 工作流详解:基于 Antigravity 的项目与 Agent 状态汇报机制

2026/9/17 2:16:12 拓冰建站 浏览量
AG Kit `/status` 工作流详解:基于 Antigravity 的项目与 Agent 状态汇报机制 AG Kit/status工作流详解基于 Antigravity 的项目与 Agent 状态汇报机制【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit/status是 AG KitAntigravity-first agent engineering kit内置的 13 个斜杠命令工作流之一用于在任何开发会话中快速汇总项目快照与多 Agent 执行进度。本文以.agents/workflows/status.md为骨架结合.agents/scripts/下的真实实现源码完整讲解/status的输出结构、底层数据来源、依赖的编排与记忆技能以及如何在你的项目里复现和扩展这一状态看板能力。一、workflow 定义从 frontmatter 看/status的契约AG Kit 的每个 workflow 都是一个带 YAML frontmatter 的 Markdown 文件.agents/workflows/status.md的头部即声明了该命令的完整契约--- name: status description: Display agent and project status. Progress tracking and status board. version: 1.0.0 requires_agents: orchestrator requires_skills: context-compression, memory-system artifact_outputs: status-report ---逐字段解读字段值含义namestatus斜杠命令名即 Antigravity 中通过/status触发descriptionDisplay agent and project status...供运行时发现与路由使用的一句话说明version1.0.0严格 SemVer 版本号AG Kit 的托管组件全部采用 SemVer 契约requires_agentsorchestrator需要加载orchestrator编排角色来完成汇总requires_skillscontext-compression, memory-system依赖两项技能长会话上下文压缩与持久记忆系统artifact_outputsstatus-report该工作流产出的工件类型会被记录进托管组件注册表这些依赖并非口头约定——在.agents/manifest.json的status条目中可以看到与 frontmatter 完全一致的结构化记录requires.agents、requires.skills、artifactOutputs说明 workflow 元数据会被生成工具解析并纳入manifest.json组件注册表保证整个工具包的可复现性。二、任务定义/status到底展示什么根据.agents/workflows/status.md的 Task 章节/status的核心任务是展示当前项目与 Agent 的运行状态输出分为四大板块1. Project Info项目信息项目名称与路径技术栈Tech stack当前已实现的功能特性Current features2. Agent Status BoardAgent 状态面板哪些 Agent 正在运行哪些任务已完成哪些工作处于待办Pending状态3. File Statistics文件统计已创建文件数量Files created count已修改文件数量Files modified count4. Preview Status预览状态本地预览服务器是否在运行访问 URL健康检查Health check结果这四块信息恰好覆盖了一个多 Agent 协作会话中最常被问到的四类问题我们在做什么做到哪一步了改了多少文件能不能打开看看三、标准输出示例逐段解读原文档给出了一份完整的模拟输出这是/status应答的推荐格式Agent 在生成状态报告时应遵循这一骨架 Project Status Project: my-ecommerce Path: C:/projects/my-ecommerce ️ Type: nextjs-ecommerce Status: active Tech Stack: Framework: next.js Database: postgresql Auth: clerk Payment: stripe ✅ Features (5): • product-listing • cart • checkout • user-auth • order-history ⏳ Pending (2): • admin-panel • email-notifications Files: 73 created, 12 modified Agent Status ✅ database-architect → Completed ✅ backend-specialist → Completed frontend-specialist → Dashboard components (60%) ⏳ test-engineer → Waiting Preview URL: http://localhost:3000 Health: OK注意输出中的几个设计细节状态符号语义化✅表示已完成Completed、表示进行中带进度百分比、⏳表示等待Waiting一屏之内即可扫出阻塞点Features 与 Pending 分开已完成特性与待办需求并列展示既反映当前成果也暴露剩余工作Agent 与业务状态分离先列项目事实技术栈、文件数再列执行主体Agent状态最后落到可访问的预览地址形成做了什么 → 谁在做 → 能不能看的完整闭环。其中Pending 列表正是context-compression技能所强调的保留关键决策、压缩已完成过程思想的体现——状态看板只保留待办与结果而非过程噪音。四、底层实现session_manager.py如何采集项目状态原文档的 Technical 章节明确/status依赖两个脚本其中第一个是python .agents/scripts/session_manager.py status阅读.agents/scripts/session_manager.py源码该脚本同时支持status与info两个子命令info输出 JSON 格式的 package.json 分析结果可以看到上文中 Project Info 板块的真实数据来源技术栈检测analyze_package_json脚本读取项目根目录的package.json合并dependencies与devDependencies后按优先级推断技术栈if next in all_deps: stack.append(Next.js) elif react in all_deps: stack.append(React) elif vue in all_deps: stack.append(Vue) elif svelte in all_deps: stack.append(Svelte) elif express in all_deps: stack.append(Express) elif nestjs in all_deps or nestjs/core in all_deps: stack.append(NestJS) if tailwindcss in all_deps: stack.append(Tailwind CSS) if prisma in all_deps: stack.append(Prisma) if typescript in all_deps: stack.append(TypeScript)由此可以推断框架检测采用优先链Next.js → React → Vue → Svelte → Express → NestJS命中一个即停止样式、ORM 与语言层Tailwind、Prisma、TypeScript采用叠加式检测可同时出现多个同一函数还会返回name、version与scripts键列表对应输出中的 Project与️ Type字段。功能特性检测detect_featuresFeatures 列表并非手工维护而是通过目录启发式从src/下自动提取遍历components、modules、features、app、pages、services等常见目录将每个子目录名视为一个候选特性并限制最多输出 10 个features[:10]。文件统计count_files文件计数会排除.git、node_modules、.next、dist、build、.agents、__pycache__等目录避免将依赖与构建产物计入项目工作成果。源码注释也坦诚说明目前统计的是追踪文件总数而创建/修改数量的精确跟踪需要依赖git diff或更完整的历史记录——这属于已知的简化实现Agent 在汇报文件统计时可直接引用 git 数据来补全 created/modified 两个维度。五、底层实现auto_preview.py如何汇报预览状态/status的 Preview 板块对应第二个脚本python .agents/scripts/auto_preview.py status.agents/scripts/auto_preview.py是预览服务器管理器完整支持start/stop/status三个子命令与.agents/workflows/preview.md中的/preview start、/preview stop、/preview restart、/preview check命令一一对应。其状态机制的核心是两个状态文件文件作用.agents/preview.pid记录预览进程 PIDis_running()通过os.kill(pid, 0)探测进程是否存活.agents/preview.log保存启动时的 stdout/stderr 日志便于排查启动失败关键实现细节启动读取项目package.json的scripts优先npm run dev其次npm start若两者都不存在则报错退出通过环境变量注入PORT并以shellTrue启动子进程兼容 Windows 的 npm 路径解析停止非 Windows 平台先发SIGTERM优雅终止Windows 平台调用taskkill /F /T /PID最后清理 PID 文件状态查询status_server()通过 PID 文件存活探测判断运行状态并输出 Preview Status 报告由于 URL 采用启发式默认http://localhost:3000源码注释特别标注了 (Likely)说明精确 URL 的保存是未来可改进项。这些细节解释了/status中 Preview 板块的 URL与 Health: OK是如何被机器化判断的URL 来自 PID 存活探测 默认端口推断Health 则等价于进程存活检测。若要更严格的健康检查可在 workflow 中进一步调用auto_preview.py status之外的端口探测逻辑。六、依赖技能为什么/status需要 memory-system 与 context-compressionrequires_skills声明的两项技能对应的是状态汇报前后的两个动作1.memory-system让状态可追溯.agents/skills/memory-system/SKILL.md提供跨会话持久记忆.agents/memory/MEMORY.md索引文件上限 200 行、每条目不超过 150 字符 按主题拆分的 topic 文件user-preferences.md、project-conventions.md、tech-decisions.md、feedback-history.md。/status汇总的待办Pending与已完成特性正是这类需要沉淀到记忆中的项目事实——新会话启动时通过索引即可恢复上下文无需重新向 Agent 解释。2.context-compression让状态只留结论.agents/skills/context-compression/SKILL.md面向 20 轮的长会话提供三级压缩Micro-Compact压缩工具输出、Phase Summary阶段总结、Full Session Archive整场归档。状态看板输出的本质就是一种Phase Summary——它用简洁的符号化结论替代冗长的过程记录从而在长会话中持续释放上下文窗口。3.orchestrator状态的执行主体requires_agents: orchestrator意味着/status由.agents/agent/orchestrator.md定义的编排角色驱动。该角色的最终响应契约## Orchestration result→ Completed / Agent contributions / Validation / Remaining decisions与/status的Agent 状态面板 待办结构高度同构——状态汇报本质上就是编排过程的可视化中间产物。七、在 AG Kit 中的定位与使用建议从.agents/ARCHITECTURE.md的 13 个 workflow 清单/brainstorm、/coordinate、/create、/debug、/deploy、/enhance、/orchestrate、/plan、/preview、/remember、/status、/test、/verify可以看出/status是会话编排链路中的观测节点/plan之后跟进/status确认进度/verify前后用/status记录变更/preview启动的服务状态也由/status统一呈现。实际使用建议在长会话中定期触发结合context-compression的触发条件20 轮后主动压缩压缩完成后紧跟一次/status让看板反映压缩后的最新状态与/remember配合状态看板中新出现的待办或已确认的技术决策可通过/remember存入memory-system实现状态 → 记忆的闭环沉淀结合 git 补充精确统计session_manager.py的 created/modified 统计目前是简化实现仅统计排除目录后的文件总数如需精确的创建/修改数字可在此基础上运行git diff --stat获取权威数据检查托管完整性由于manifest.json记录了status工作流的元数据路径、版本、依赖、工件修改本 workflow 后应运行python .agents/scripts/generate_manifest.py --check与python .agents/scripts/validate_kit.py重新校验注册表。总结/status是 AG Kit 中连接执行与观测的轻量工作流它以session_manager.py的静态项目分析为数据底座以auto_preview.py的进程探测为运行态来源通过orchestrator编排汇总并依赖memory-system与context-compression实现状态的可持久化与可压缩。理解它的 frontmatter 契约与底层脚本实现你就能在自己的项目中复刻一套同样简洁、符号化、可机器判读的 Agent 状态看板。【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考