AI 驱动开发生命周期(AI-DLC)的难点,通常不在于让模型生成一段代码,而在于把一个模糊想法稳定地推进到可运行、可验证、可维护的实现。Amazon Bedrock AgentCore、Kiro 和 Claude Code 提供了一条适合工程团队的实践路径:让 AI 参与需求拆解、方案设计、代码构建和验证,同时保留明确的上下文、工具边界与人工审查点。
相关参考实现聚焦两个容易验证价值的场景:把 SQL DDL 转换为 ER 图,以及用多智能体协作分析代码安全问题。前者适合展示从自然语言或结构化输入到可视化产物的构建过程,后者则体现了多个专职智能体如何分工完成更复杂的工程任务。
从“让模型写代码”转向“让流程可执行”
AI-DLC 的 construction 阶段不是一次性生成最终答案,而是将工作拆成一组可检查的中间产物:
- 明确需求、输入和验收标准。
- 生成技术方案与任务分解。
- 使用代码代理实现最小可运行版本。
- 运行测试、静态检查或安全扫描。
- 根据结果修复并再次验证。
在这个过程中,AgentCore 可以作为智能体运行时和工具集成的承载层,Kiro 可以帮助团队把需求、规格和任务组织起来,Claude Code 则适合在代码仓库中执行编辑、测试和诊断。具体组件边界应根据团队的权限模型、部署方式和审计要求确定,不应把模型输出直接视为可信代码。
一个实用的工作项可以包含以下内容:
目标:从 schema.sql 生成可审查的 ER 图
输入:SQL DDL,支持 CREATE TABLE、主键和外键
输出:Mermaid erDiagram 文件
验收标准:
- 每张表都出现在图中
- 主键和外键关系可追踪
- 无法解析的语句被记录,不静默丢弃
- 生成脚本可重复运行
这类规格比“帮我做一个 SQL 转 ER 图工具”更适合交给 Kiro 或 Claude Code,因为它明确了输入、输出、范围和失败行为。
参考实现一:SQL 到 ER 图
SQL-to-ER-diagram 是一个很好的构建阶段样例。它的核心链路可以保持简单:读取 DDL,提取表和关系,生成 Mermaid 或其他图形描述格式,再由渲染工具展示。
下面的脚本只使用 Python 标准库,支持常见的 CREATE TABLE、主键字段和 REFERENCES 外键定义。它是一个可直接运行的最小实现,真实项目中可以继续替换为更完整的 SQL parser,以覆盖不同数据库方言。
将内容保存为 sql_to_mermaid.py,再准备一个 schema.sql:
import re
import sys
from pathlib import Path
def build_er_diagram(sql: str) -> str:
tables = {}
relationships = []
table_pattern = re.compile(
r"CREATE\\s+TABLE\\s+(?:IF\\s+NOT\\s+EXISTS\\s+)?([\\w.]+)\\s*\\((.*?)\\);",
re.IGNORECASE | re.DOTALL,
)
for match in table_pattern.finditer(sql):
table_name = match.group(1).split(".")[-1]
columns = []
body = match.group(2)
for raw_line in body.splitlines():
line = raw_line.strip().rstrip(",")
column_match = re.match(r"([\\w]+)\\s+([A-Za-z0-9_()]+)", line)
if not column_match:
continue
name, data_type = column_match.groups()
is_pk = bool(re.search(r"\\bPRIMARY\\s+KEY\\b", line, re.IGNORECASE))
columns.append((name, data_type, "PK" if is_pk else ""))
fk_match = re.search(
r"REFERENCES\\s+([\\w.]+)\\s*\\(\\s*([\\w]+)\\s*\\)",
line,
re.IGNORECASE,
)
if fk_match:
target_table = fk_match.group(1).split(".")[-1]
target_column = fk_match.group(2)
relationships.append((table_name, target_table, name, target_column))
tables[table_name] = columns
output = ["erDiagram"]
for table_name, columns in tables.items():
output.append(f" {table_name} {{")
for name, data_type, marker in columns:
suffix = f" {marker}" if marker else ""
output.append(f" {data_type} {name}{suffix}")
output.append(" }")
for source, target, source_col, target_col in relationships:
output.append(f" {source} }}o--|| {target} : \"{source_col} references {target_col}\"")
return "\\n".join(output) + "\\n"
if __name__ == "__main__":
if len(sys.argv) != 2:
raise SystemExit("usage: python sql_to_mermaid.py schema.sql")
sql_file = Path(sys.argv[1])
print(build_er_diagram(sql_file.read_text(encoding="utf-8")))
示例输入:
CREATE TABLE users (
id INTEGER PRIMARY KEY,
email VARCHAR(255) NOT NULL
);
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
user_id INTEGER REFERENCES users(id),
total DECIMAL(10, 2) NOT NULL
);
运行:
python sql_to_mermaid.py schema.sql > schema.mmd
生成的 schema.mmd 可以交给 Mermaid 渲染器。把这个最小脚本交给 Claude Code 时,任务可以进一步拆成“增加 PostgreSQL schema 支持”“为无法解析的 DDL 增加警告”“补充单元测试”等小步骤。这样,代理每次修改的范围更小,失败原因也更容易定位。
在 AgentCore 中部署类似能力时,可以把 SQL 解析和图表生成封装成受限工具。智能体负责理解请求和选择工具,工具只接收必要输入并返回结构化结果。生产环境应限制数据库访问、文件路径和输出格式,避免把任意 SQL 执行能力暴露给模型。
参考实现二:多智能体代码安全分析
代码安全分析比单个规则扫描更适合采用多智能体工作流,因为不同问题需要不同的上下文和判断方式。一个可以实践的角色划分如下:
- 协调智能体:读取任务和仓库范围,分发分析工作,合并结果。
- 依赖分析智能体:检查依赖清单、版本风险和已知漏洞数据接入点。
- 代码审计智能体:关注注入、认证、授权、敏感信息泄露等代码路径。
- 测试智能体:为高风险发现生成复现步骤或回归测试建议。
- 审查智能体:去重、判断置信度,并把问题映射到文件和行号。
关键不在于智能体数量,而在于每个角色都有明确的输入、输出和权限。例如,代码审计智能体可以只读访问仓库,测试智能体可以在隔离环境中运行测试,协调智能体不能自行修改生产配置。
一个适合交给 Kiro 或 Claude Code 的任务协议可以写成:
workflow: repository-security-review
input:
repository: ./src
branch: current
language: python
agents:
- name: dependency-reviewer
responsibility: inspect dependency manifests and report risky versions
output: findings.json
access: read-only
- name: code-auditor
responsibility: inspect data flows for injection and secret exposure
output: findings.json
access: read-only
- name: verifier
responsibility: validate high-confidence findings with isolated tests
output: verification.json
access: sandbox
review:
required_fields:
- rule_id
- severity
- file
- line
- evidence
- remediation
deduplicate_by:
- rule_id
- file
- line
human_approval_required_for:
- code_changes
- dependency_upgrades
统一输出格式很重要。没有结构化结果时,多个智能体很容易重复报告同一个问题,或者把“可能存在风险”写成没有证据的结论。每条发现至少应包含规则编号、严重级别、文件、行号、证据、影响和修复建议。对高风险问题,还应记录验证步骤和未验证的假设。
一个安全的执行顺序可以是:
# 1. 先锁定分析范围,避免代理扫描不相关目录
find ./src -type f \\
\( -name '*.py' -o -name 'pyproject.toml' -o -name 'requirements*.txt' \) \\
-print
# 2. 使用现有工具提供确定性结果,再交给智能体解释上下文
python -m compileall ./src
ruff check ./src
bandit -r ./src -f json -o bandit.json
# 3. 让审查智能体基于扫描结果和只读代码上下文生成 findings.json
这里的命令假设项目已经安装 ruff 和 bandit。实际流水线可以把确定性扫描器作为前置步骤,把智能体用于跨文件分析、风险解释和修复建议,而不是让模型取代所有安全工具。这样既能减少幻觉,也能让结果更容易接入 CI 门禁。
让 AgentCore、Kiro 和 Claude Code 协同工作
三者可以形成互补关系,但不必强行绑定为一个复杂平台:
- 用 Kiro 维护需求、规格、任务分解和验收标准。
- 用 Claude Code 在代码仓库中完成实现、测试和局部修复。
- 用 Amazon Bedrock AgentCore 承载需要工具调用、隔离执行、身份控制或长期运行的智能体工作流。
建议让每一轮工作都留下可审查产物,例如 spec.md、tasks.md、测试报告和安全发现 JSON。智能体的上下文应来自这些文件和明确允许访问的代码,而不是依赖聊天窗口中不可追溯的临时指令。
还需要提前定义失败策略:SQL 无法解析时输出错误位置;安全分析超时时保留已经完成的角色结果;工具调用失败时不伪造成功状态;模型提出代码修改时先生成补丁,再经过测试和人工审批。对于涉及凭证、客户代码或内部仓库的场景,权限、日志和数据保留策略应在部署前确定。
落地检查清单
可以从一个小而封闭的用例开始,按下面的顺序验证:
- 输入是否有明确格式,边界是否可枚举?
- 是否存在可重复运行的构建命令和测试命令?
- 每个智能体是否只有完成任务所需的最小权限?
- 中间结果是否结构化,并且能够追踪到文件、行号或输入片段?
- 失败时是否明确报告“不确定”而不是生成看似完整的答案?
- 生成代码是否必须经过测试、静态检查和人工审批?
- 成本、延迟、模型调用日志和敏感数据处理是否可观测?
AI-DLC 的价值最终取决于工程闭环,而不是单次生成质量。SQL 到 ER 图可以作为低风险入口,多智能体安全分析则可以检验团队在权限隔离、结果验证和审计方面的成熟度。先把一个 construction 工作流做成可重复、可验证的流水线,再逐步扩大智能体的职责范围,通常比一开始构建全自动开发系统更稳妥。