对残障学生而言，从学校走向高等教育、职业培训或就业，不只是生成一份普通的学习计划。规划过程需要理解学生的能力、兴趣、支持需求和家庭意见，还要符合美国《残障人士教育法案》（IDEA）中的过渡规划要求。Trinity 的案例展示了一个重要方向：把对话式 AI 从单一问答工具扩展为基于 Amazon Bedrock 的无服务器多智能体系统，为美国各地学区生成更具结构化和可执行性的过渡计划。
从聊天机器人到规划系统
普通聊天机器人通常围绕“输入问题，生成回答”运行。但过渡规划需要多个相互衔接的任务：
- 通过对话收集学生的目标、优势、兴趣和支持需求。
- 识别教育、就业、独立生活等不同领域的规划信息。
- 检查内容是否覆盖 IDEA 相关要求。
- 将信息整理成学校工作人员可以审阅和执行的计划。
- 在缺少信息、存在歧义或涉及敏感判断时要求人工介入。
因此，系统的核心不应只是一个更大的模型，而是清晰的任务分工和可追踪的工作流。可以把它拆成多个专业智能体：访谈智能体负责提问，分析智能体负责提取结构化信息，合规智能体负责检查完整性，计划智能体负责生成草案，审阅智能体负责指出风险和缺口。
这种拆分有两个直接好处。其一，每个智能体的提示词和输出格式更容易测试。其二，学区可以知道一项建议是由哪个步骤产生的，便于教师、家长和学生共同审阅，而不是把最终文本当成不可解释的黑盒结果。
为什么采用无服务器多智能体架构
面向美国多个学区部署时，系统需要同时处理不同规模的会话、学校和地区配置。无服务器架构可以让计算资源随请求变化，减少长期维护服务器集群的负担。一个可行的逻辑链路如下：
- 前端或学校系统提交一次学生访谈输入。
- API 层对用户身份、租户和请求格式进行校验。
- 工作流服务调用不同的 Bedrock 智能体或模型步骤。
- 每个步骤输出结构化 JSON，而不是直接输出一段不可解析的长文本。
- 工作流保存中间状态、审阅记录和最终计划。
- 学校工作人员在发布前确认内容，并处理需要人工判断的事项。
在 AWS 中，可以根据组织现有能力组合 API Gateway、Lambda、Step Functions、Amazon Bedrock、DynamoDB 和 CloudWatch。这里的关键不在于服务数量，而在于边界设计：模型负责语言理解和草案生成，业务系统负责权限、状态、审计和发布控制。
对残障学生数据尤其要谨慎。系统应尽量减少不必要的个人信息，按学区和角色实施访问控制，对提示词、模型响应和计划版本建立审计记录，并在产品层面明确 AI 生成内容必须经过合格人员审阅。IDEA 对教育服务和个体支持的要求不能被简单等同为模型输出格式，合规检查只能辅助工作人员，不能替代专业判断。
一个可改造的 Bedrock 工作流示例
下面的示例演示一个最小化的“分析智能体 + 计划智能体”流程。它假设已经在 AWS 区域中配置了可调用的 Bedrock 模型，并通过环境变量提供模型 ID。示例使用 converse API，适合放入 Lambda 或普通 Python 服务中改造；真实系统还需要加入认证、租户隔离、持久化和人工审批。
运行前准备：
- 配置 AWS 凭证和默认区域，例如
AWS_REGION=us-east-1。 - 设置一个当前账户可访问的 Bedrock 模型 ID。
- 确认 IAM 权限包含对应模型的调用权限。
- 不要在测试数据中使用真实学生姓名、联系方式或其他不必要的身份信息。
import json
import os
from typing import Any
import boto3
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]
REGION = os.getenv("AWS_REGION", "us-east-1")
bedrock = boto3.client("bedrock-runtime", region_name=REGION)
def call_agent(system_prompt: str, user_payload: dict[str, Any]) -> dict[str, Any]:
response = bedrock.converse(
modelId=MODEL_ID,
system=[{"text": system_prompt}],
messages=[
{
"role": "user",
"content": [{"text": json.dumps(user_payload, ensure_ascii=False)}],
}
],
inferenceConfig={"temperature": 0.2, "maxTokens": 1200},
)
text = response["output"]["message"]["content"][0]["text"]
return json.loads(text)
def build_transition_plan(student_input: str) -> dict[str, Any]:
extracted = call_agent(
"""
你是过渡规划信息提取智能体。只返回合法 JSON，不要输出 Markdown。
字段必须为 strengths、interests、education_goals、employment_goals、
independent_living_needs、supports、missing_information。
不要猜测没有提供的事实；缺少的信息放入 missing_information。
""",
{"student_input": student_input},
)
plan = call_agent(
"""
你是学校过渡计划草案智能体。只返回合法 JSON，不要输出 Markdown。
字段必须为 student_vision、measurable_goals、services_and_supports、
responsible_parties、timeline、review_questions。
所有目标都必须明确指出依据的已知信息；无法确定的内容写入 review_questions。
不要做医疗、法律或能力诊断，不要替代学校工作人员的专业判断。
""",
{"extracted_profile": extracted},
)
return {
"profile": extracted,
"draft_plan": plan,
"requires_human_review": True,
}
if __name__ == "__main__":
sample = (
"学生喜欢计算机维修，希望毕业后参加职业培训；在公共交通和工作场所沟通方面需要支持。"
)
print(json.dumps(build_transition_plan(sample), ensure_ascii=False, indent=2))
这个示例刻意把中间结果限制为 JSON。实际部署时，可以将两个调用拆成 Step Functions 的不同状态，并把输入和输出保存到 DynamoDB。若某一步返回无效 JSON、发现关键字段缺失，或检测到需要专业人员判断的内容，工作流应进入人工审阅状态，而不是继续自动发布。
多学区扩展时需要解决的问题
租户隔离
不同学区可能拥有不同的表单字段、审批流程、支持资源和文档模板。应在每次请求中显式传递 district_id，并在数据库分区键、授权策略和日志字段中保持一致。不能只依赖模型提示词来实现数据隔离。
输出可追踪
一份计划不应只有最终文本。建议同时保存：输入摘要、结构化提取结果、使用的提示词版本、模型标识、生成时间、审阅者、修改记录和发布状态。这样才能解释计划如何形成，也便于发现某个提示词版本带来的系统性问题。
质量评估
评估指标不能只看语言是否流畅，还应检查：
- 是否忠实于学生提供的信息。
- 是否覆盖教育、就业和独立生活等相关目标。
- 是否提供了可执行、可衡量的目标。
- 是否正确标记了缺失信息和不确定内容。
- 是否存在刻板印象、过度推断或不适当的建议。
- 教师、家长和学生是否能够理解并修订结果。
对于这类高影响场景，离线评测集、人工抽检和持续反馈比单纯提高模型温度或更换模型更重要。
落地建议
Trinity 这类系统的价值，不只是“让 AI 写出一份计划”，而是把复杂的访谈、信息整理、要求检查和人工审阅组织成一个可扩展的服务流程。采用时可以遵循以下边界：
- 先明确计划 schema 和审批状态，再设计智能体。
- 让每个智能体只负责一个可测试的任务。
- 使用结构化输出承载中间状态，减少自由文本在步骤之间流动。
- 把身份、权限、审计和数据保留策略放在应用层控制。
- 将 AI 结果定位为可编辑草案，而不是自动生效的教育决定。
- 用真实工作流程中的教师、家长和学生反馈持续校准系统。
当模型能力与严格的工作流、隐私控制和人工责任边界结合起来时，多智能体架构才适合进入教育和残障支持等高敏感领域。