核心问题: 这些 Markdown Agent 定义与 Shell 脚本是否足够安全，可以直接导入你的内部 AI 流程而不会引入提示注入或凭证泄露？
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 88/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 4 个来源、覆盖 3 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 6 个工作流步骤、4 个下一步动作，以及 1 个命令/安装信号。
趋势热度为 +1,793 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 medium，并包含 5 条安全说明与 3 条跳过条件。
3 个机会视角、4 个替代方案，以及 3 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 4 个 AI/Agent 相关信号。
项目概览
msitarzewski/agency-agents 把自己定位为一座完整的 AI 代理机构：一组按 16 个部门组织的专业 Agent，其中包含专门的安全部门，覆盖安全架构、应用安全、渗透测试、威胁情报与事件响应。仓库主要使用 Shell 与 Markdown 编写，交付物是提示词定义加上安装、转换与校验脚本，而不是编译后的二进制。
该项目在 2026-07-01 周期内获得 1793 颗星，并位列趋势榜第 1 名。其吸引力从结构上就能看出：每个 Agent 是一个带 frontmatter 的 Markdown 文件，按 engineering、design、finance、gis、security 等带标签目录组织。CONTRIBUTING.md 明确指出 divisions.json 是部门集合的唯一事实来源，并由 scripts/check-diventions.sh 在 CI 中校验。
从安全工具的视角看，值得关注的面不仅是安全部门的 Agent，还包括仓库自身对风险的处理。SECURITY.md 把内容分为两类：不可执行且不得存放密钥的 Markdown Agent 文件，以及 scripts/ 下需要贡献者在运行前审查的可执行脚本。这种划分使该仓库成为构建内部 Agent 目录时的有效参考案例，帮助团队避免引入提示注入或未审查的 Shell 代码。
为什么现在变热
- 单周期 1793 颗星，并在 2026-07-01 排名趋势第 1，得益于低门槛的 Markdown 格式，非工程人员也能直接阅读与修改 Agent 定义。
- 16 个命名部门，包括 security、academic、engineering、gis、spatial-computing 与 specialized，覆盖面广且不要求用户绑定某个框架。
- 文档化的安全策略给出 48 小时确认窗口与 7 天初步评估目标，对于一个社区提示词目录而言相当认真。
- convert.sh 脚本会在 integrations/ 下生成针对具体工具的输出，把仓库定位为 plain Markdown Agent 与下游 AI 工具之间的适配层。
解决什么问题
- Markdown Agent 文件本身不可执行，但一旦被导入 LLM 上下文，若未审查就可能携带提示注入指令。
- scripts/ 下的 Shell 脚本，尤其是 install.sh、convert.sh、lint-agents.sh，均为可执行文件，SECURITY.md 明确要求在运行前审查。
- 贡献者可以通过修改 divisions.json、scripts/convert.sh 与 scripts/lint-agents.sh 提出新部门，每次接受变更都会扩大可信面。
- strategy/ 与 integrations/ 目录被明确排除在部门清单之外，生成的产物与 playbook 可能在 CI 校验之外累积漂移。
工作原理
- 克隆仓库并先阅读 SECURITY.md，再运行任何脚本；项目把 scripts/install.sh、scripts/convert.sh、scripts/lint-agents.sh 标记为可执行且需审查。
- 查看 divisions.json 获取 16 个部门的权威清单，然后进入对应目录，例如 security/ 查看安全架构、AppSec、渗透测试、威胁情报与事件响应 Agent。
- 打开 Markdown Agent 文件，检查 frontmatter 与提示正文；SECURITY.md 要求 Agent 文件不得包含 API key、token 或凭证。
- 通过在 CI 中运行 scripts/check-divisions.sh 的行为来确认：divisions.json 中新增的目录必须同时出现在 scripts/convert.sh 与 scripts/lint-agents.sh 的 AGENT_DIRS 中，否则构建失败。
- 使用 scripts/convert.sh 在 integrations/ 下生成针对目标工具的输出，并在完成提示注入审查后再导入。
- 若发现可疑 Agent 定义或脚本行为，按 SECURITY.md 要求通过 GitHub 私密安全公告上报，而不是开公开 issue。
你真正需要审计的脚本与文件
- scripts/install.sh：SECURITY.md 标记为可执行、需在运行前由贡献者审查的安装脚本。
- scripts/convert.sh：可执行转换器，同时维护一份被部门一致性检查使用的 AGENT_DIRS 列表。
- scripts/lint-agents.sh：可执行校验器，维护第二份 AGENT_DIRS，必须与 convert.sh 和 divisions.json 一致。
- scripts/check-divisions.sh：CI 门禁，当 divisions.json、convert.sh、lint-agents.sh 不一致或部门目录没有 Agent 文件时构建失败。
- divisions.json：仓库根目录文件，为 16 个部门定义 label、icon、color，被视为唯一事实来源。
- strategy/：不含 Agent frontmatter 的 NEXUS playbook 与 runbook，明确不是部门，不参与部门校验。
- integrations/：由 convert.sh 生成的针对具体工具的输出，明确不是部门，也不属于贡献者目录。
注重安全的团队的采纳清单
- 阅读 LICENSE，确认 MIT License 的署名要求（copyright 2025 AgentLand Contributors）符合你的分发模式。
- 确认 SECURITY.md 的 48 小时确认与 7 天初步评估时间线满足你内部的漏洞响应 SLA。
- 在导入任何 Agent Markdown 文件前，搜索其正文是否存在可能重定向 LLM、泄露上下文或执行 Shell 命令的指令。
- 在运行 install.sh、convert.sh 或 lint-agents.sh 前，与上次审查过的 commit 做 diff，并追踪每一条 Shell 操作。
- 锁定到具体 commit，并关注 release 或 commit 通知，以便在升级前审查新增 Agent 文件或脚本变更。
长期使用的维护风险
维护模型依赖三个可执行脚本与一个 JSON 文件保持同步。CONTRIBUTING.md 要求新部门必须同时加入 divisions.json、scripts/convert.sh 的 AGENT_DIRS 与 scripts/lint-agents.sh 的 AGENT_DIRS。当三者不一致或目录中没有 Agent 文件时，check 会让构建失败，这是一个有意义的护栏。
残留风险在于 strategy/ 与 integrations/ 不受同一检查覆盖。strategy/ 存放没有 Agent frontmatter 的 NEXUS playbook 与 runbook，integrations/ 存放 convert.sh 生成的针对具体工具的输出。两者都不是部门，CONTRIBUTING.md 明确警告不要把它们加入部门清单，因此提示与配置漂移可能在 CI 门禁之外累积。
谁适合关注
适合关注
- 希望用带标签部门与 frontmatter 的可读模板来组织内部 Agent 目录的安全团队。
- 能在导入前审查 Markdown 提示中提示注入模式的应用安全与威胁情报从业者。
- 正在基于 check-divisions.sh 为自己的多目录提示库构建 CI 门禁的平台团队。
可以先跳过
- 无法承诺在每次合并前审查 Shell 脚本的团队，因为 install.sh、convert.sh、lint-agents.sh 都是可执行且需审查的。
- 把 Agent Markdown 文件默认视为可信的环境，因为 SECURITY.md 明确要求报告尝试提示注入的可疑定义。
- 需要编译型、沙箱化运行时而非纯 Markdown 加 Shell 胶水的项目。
风险与注意事项
仓库是 MIT 授权的 Markdown 与 Shell，但其可执行脚本与外部 Agent 定义在每次导入或合并前都需要人工审查。
- SECURITY.md 把 install.sh、convert.sh、lint-agents.sh 归类为可执行脚本，要求贡献者在运行或合并前审查。
- Agent Markdown 文件是被导入 LLM 上下文的提示定义，贡献者指南中把提示注入列为已知风险。
- CI 门禁只校验 divisions.json、convert.sh、lint-agents.sh 的一致性，不覆盖 strategy/ 的 playbook 与 integrations/ 的生成产物。
- 新增部门会扩展两个脚本中的可信 AGENT_DIRS 列表，随着目录增长审查负担也随之上升。
- SECURITY.md 要求报告者通过 GitHub 私密安全公告上报漏洞，而不是开公开 issue。
- 声明的响应时间线为 48 小时内确认、7 天内初步评估。
- Agent Markdown 文件是不可执行的提示定义，不得包含 API key、token 或凭证。
- 贡献者被要求报告尝试提示注入的可疑 Agent 定义。
- scripts/ 下的 Shell 脚本在合并前必须审查，策略中按名称列出了 install.sh、convert.sh、lint-agents.sh。
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
crewAI | 当你需要带运行时编排的 Python 框架，而不是 Markdown 提示文件加 Shell 胶水时。 | 开源 |
LangGraph | 当你的安全审查更偏好基于图的 Agent 状态与带类型的 Python 接口，而非纯 Markdown 定义时。 | 开源 |
| 当你想要带社区插件的自治 Agent 运行时，并接受可执行 Agent 代码带来的更重审查负担时。 | 开源 | |
内部提示库 | 当你的组织已经在私有仓库中维护经过审查的 Markdown 提示，并自带校验流水线时。 | 内部自建 |
这个趋势说明了什么
把 divisions.json 模式克隆到自有目录
以单一事实来源 JSON 加 CI 校验来强制 divisions.json、convert.sh、lint-agents.sh 三者一致，是一个可复用的模式，适合任何维护带标签目录的提示或 runbook 的团队。
本地复现：从任一脚本的 AGENT_DIRS 中删除一个部门，确认构建会失败。
在 lint-agents.sh 中增加提示注入检查
仓库已经在 CI 中运行 lint-agents.sh，并要求贡献者报告提示注入尝试，这为增加基于规则的检查提供了具体落点。
针对现有 Agent Markdown 文件原型一组 grep 规则，先测量误报率，再决定是否提交上游。
发布带签名 Agent 文件的加固分叉
需要 Agent 来源可信的团队可以分叉该目录，保留 MIT License 署名，并增加 commit 签名与已审查 Agent 清单。
确认 convert.sh 可以在不修改的情况下消费签名清单，或记录所需的最小补丁。
RepoDaily 判断
Agency-Agents 是一个结构清晰的 Markdown 加 Shell 目录，具备真实的安全策略、命名安全部门与用于目录一致性的 CI 门禁；是否采纳的关键在于你的团队是否愿意在每次导入前审查每个可执行脚本与 Agent 提示。