用 Amazon Bedrock AgentCore 落地 AI 驱动开发生命周期:从 SQL 建模到多智能体代码安全分析

2026-09-04 30 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:13 分钟

AI 驱动开发生命周期(AI-DLC)的难点,通常不在于让模型生成一段代码,而在于把一个模糊想法稳定地推进到可运行、可验证、可维护的实现。Amazon Bedrock AgentCore、Kiro 和 Claude Code 提供了一条适合工程团队的实践路径:让 AI 参与需求拆解、方案设计、代码构建和验证,同时保留明确的上下文、工具边界与人工审查点。

相关参考实现聚焦两个容易验证价值的场景:把 SQL DDL 转换为 ER 图,以及用多智能体协作分析代码安全问题。前者适合展示从自然语言或结构化输入到可视化产物的构建过程,后者则体现了多个专职智能体如何分工完成更复杂的工程任务。

从“让模型写代码”转向“让流程可执行”

AI-DLC 的 construction 阶段不是一次性生成最终答案,而是将工作拆成一组可检查的中间产物:

  1. 明确需求、输入和验收标准。
  2. 生成技术方案与任务分解。
  3. 使用代码代理实现最小可运行版本。
  4. 运行测试、静态检查或安全扫描。
  5. 根据结果修复并再次验证。

在这个过程中,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

这里的命令假设项目已经安装 ruffbandit。实际流水线可以把确定性扫描器作为前置步骤,把智能体用于跨文件分析、风险解释和修复建议,而不是让模型取代所有安全工具。这样既能减少幻觉,也能让结果更容易接入 CI 门禁。

让 AgentCore、Kiro 和 Claude Code 协同工作

三者可以形成互补关系,但不必强行绑定为一个复杂平台:

  • 用 Kiro 维护需求、规格、任务分解和验收标准。
  • 用 Claude Code 在代码仓库中完成实现、测试和局部修复。
  • 用 Amazon Bedrock AgentCore 承载需要工具调用、隔离执行、身份控制或长期运行的智能体工作流。

建议让每一轮工作都留下可审查产物,例如 spec.mdtasks.md、测试报告和安全发现 JSON。智能体的上下文应来自这些文件和明确允许访问的代码,而不是依赖聊天窗口中不可追溯的临时指令。

还需要提前定义失败策略:SQL 无法解析时输出错误位置;安全分析超时时保留已经完成的角色结果;工具调用失败时不伪造成功状态;模型提出代码修改时先生成补丁,再经过测试和人工审批。对于涉及凭证、客户代码或内部仓库的场景,权限、日志和数据保留策略应在部署前确定。

落地检查清单

可以从一个小而封闭的用例开始,按下面的顺序验证:

  • 输入是否有明确格式,边界是否可枚举?
  • 是否存在可重复运行的构建命令和测试命令?
  • 每个智能体是否只有完成任务所需的最小权限?
  • 中间结果是否结构化,并且能够追踪到文件、行号或输入片段?
  • 失败时是否明确报告“不确定”而不是生成看似完整的答案?
  • 生成代码是否必须经过测试、静态检查和人工审批?
  • 成本、延迟、模型调用日志和敏感数据处理是否可观测?

AI-DLC 的价值最终取决于工程闭环,而不是单次生成质量。SQL 到 ER 图可以作为低风险入口,多智能体安全分析则可以检验团队在权限隔离、结果验证和审计方面的成熟度。先把一个 construction 工作流做成可重复、可验证的流水线,再逐步扩大智能体的职责范围,通常比一开始构建全自动开发系统更稳妥。


相关推荐